Today's Posts

Post questions about C, C++, Java, SQL, and other programming languages here.

Compiler/Runtime uses of sizeof

programming, solved

Login to Reply

Thread Tools Search this Thread
# 1  
Old 12-14-2015
Compiler/Runtime uses of sizeof

Ignoring other considerations for a moment and in general ...
Would there be a difference in result (dot oh or execution) of:

   strncpy( a, b, sizeof(a) );


   c = sizeof(a);
   strncpy( a, b, c );

My general understanding is (at least I think my understanding is) that in cases where something is inherently fixed in size then the compiler inserts the literal value of the size of the item at compile time as opposed to leaving an implicit run-time function call.

If my understanding is correct then it seems in scenario A. we'd have strncpy( a, b, 4 ) in one line of execute compared to two lines in B.: c = 4; strncpy( a, b, c ).

Is that not correct?
Am I missing something?
Thanks in advance for any comments.
Geo. Salisbury
Long Valley, NJ

Last edited by GSalisbury; 12-14-2015 at 05:04 PM.. Reason: Grammer
# 2  
Old 12-14-2015
Ignoring other considerations makes it impossible to give you a useful answer.
  1. Have you included <string.h>? If not, what function prototype did you supply for strncpy(), if any?
  2. Have you included <sys/types.h>?
  3. How is a declared?
  4. How is c declared?
  5. What programming environment are you using?
# 3  
Old 12-14-2015
1. & 2. Yes


have been included.
3. An example a might be char

4. An example c might be
int c = sizeof(a)

5. Using gcc on RedHat Linux boxes.

What I was after is what, if any, would be the virtue of using:
c = sizeof(a); strncpy( a, b, c );

strncpy( a, b, sizeof(a) );

I'm not a C maven (I can kludge along given good consult) but it seems to me that using the sizeof value in a separate int adds overhead while not altering the execution result.

I appreciate that we're talking fractional nano-seconds and negligible amounts but am interested in clarifying the precept.
# 4  
Old 12-14-2015
int c = sizeof(a);

is wrong, but won't actually hurt you unless a contains more bytes than fit in an object of type signed int. If you're using an external object to store the results of the sizeof operator, its type should be size_t; not int.

Note that if you are in a subroutine that has been passed a pointer to an array of characters to be copied into an area of memory pointed to by another pointer to an array of characters, you have to be also be given the size of the destination array, as in:
char *my_copy(char *from, char *to, size_t to_size) {
        return(strncpy(to, from, to_size);

because using:
        return(strncpy(to, from, sizeof(to));

gives you the size of the pointer to; not the size of the array of characters pointed to by to.

But, as long as the compiler knows the size of the destination object as in:
#include <string.h>
int main() {
        char a[128], b[]="source string", *ret;
        ret = strncpy(a, b, sizeof(a));

there is no need to create a variable to hold the result of the sizeof operator before calling strncpy().

Last edited by Don Cragun; 12-14-2015 at 06:51 PM..
# 5  
Old 12-15-2015
I have to bail on this for now - will pick it back up tomorrow after considering your comments.

---------- Post updated 12-15-15 at 05:19 PM ---------- Previous update was 12-14-15 at 05:50 PM ----------

Finally able to return ...

The ability of 'c' to hold the

would not be a concern as 'a' is defined as an eight character, fixed-length string
char a[8]

for example.

All is happening in a closed domain of a running application. The present method in place is the one-step

. The two-step approach came up as quote better but it struck me as accomplishing nothing different and "cost" the teensy bit of the size of the default int.

We'll leave the strncpy... as is with the sizeof... as one of the arguments.
Thanks for your thoughts.
# 6  
Old 01-17-2016
You seriously don't need to worry about overhead of an extra line of code.
Lets do some rough guess calculation here...
What you got a 2GHZ processor? That's 2000,000,000 cycles per second.

Lets say that extra line adds 20 cycles on the program. That's a 10 millionth of a second.
Reading a few bytes from a disk may well take in the order of milliseconds.

If you think it makes the program clearer then do it. I routinely add extra steps and variables to make my code more readable and I deal with vast amounts of 24 hour streaming data.
And my stuff flies.

Its I/O that causes bottlenecks.
# 7  
Old 01-18-2016
The original query was not overtly based upon concerns of overhead or performance per se but, rather, [possible?] quote technical differences in compiled result.

The illustrated fragments using sizeof as arguments were in place in an area that was already selective in execution and time and volume did not come into play.

A discussion had started on the merits of an argument vs. a variable and the posting here was more for enlarging the set of opinions. I, too, will often include additional steps etc. in order to make a sequence more clear or to be able to include some step-wise commentary.

The upshot was we (I) left the use of the sizeof as arguments in place as is principally because we (I<g>) didn't have to do anything (Management 101 - 1st precept - do nothing) and because the use was in a block that already well commented leaving no ambiguity.

Geo. Salisbury
Long Valley, NJ
Login to Reply

« Previous Thread | Next Thread »
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

More UNIX and Linux Forum Topics You Might Find Helpful
Thread Thread Starter Forum Replies Last Post
Sizeof a file from directory path in perl kiran425 Shell Programming and Scripting 1 08-28-2013 09:36 AM
sizeof(object) in C++ ramkrix Programming 2 10-20-2010 05:04 PM
Doubts regarding sizeof() operator royalibrahim Programming 5 07-21-2010 05:58 PM
How to get the sizeof char pointer SamRoj Programming 3 06-04-2009 03:58 AM
sizeof an array of structure without using 'sizeof' operator rvan Programming 18 04-01-2009 05:55 PM
How Can a Machine Reads a Compiler Since A Compiler is Written in Text! Not Binaries? f.ben.isaac Programming 12 11-14-2008 11:25 AM
XL c\c++ runtime upgrade -fp4 db2 v9.1 ak835 AIX 3 04-22-2008 09:33 AM
sizeof ramneek Programming 7 10-13-2005 08:22 AM
Runtime Error... marpin UNIX for Dummies Questions & Answers 4 02-07-2004 12:30 PM

All times are GMT -4. The time now is 08:35 PM.

Unix & Linux Forums Content Copyright 1993-2018. All Rights Reserved.
Show Password