evaluate a generic swap function

[Nelu]

2. I wouldn't do this. I'd just iterate through swapping the bytes
individually.

Slow? Maybe. But:

It could probably be made faster using a static array of unsigned chars to swap blocks if there is no need for thread safety.

It can be made thread safe using a thread local variable but it would work best (avoiding malloc for each operation) if the threads were reused. This is, however, dependent on the threading library and not on topic here.

 

[Ben Bacarisse]

It could probably be made faster using a static array of unsigned
chars to swap blocks if there is no need for thread safety.

I don't understand the static part. As you say, it introduces a problem
(for threaded code) but surely an automatic array is the way to go
anyway?

It can be made thread safe using a thread local variable but it would
work best (avoiding malloc for each operation) if the threads were
reused. This is, however, dependent on the threading library and not
on topic here.

I'd "fix" this not with thread local storage but with an automatic
array. I posted an example of block swapping this way a day or so ago.

 

[Nelu]

I don't understand the static part. As you say, it introduces a problem
(for threaded code) but surely an automatic array is the way to go
anyway?


I'd "fix" this not with thread local storage but with an automatic
array. I posted an example of block swapping this way a day or so ago.

Yes, but memory for the tmp variable in your example is allocated/deallocated every time you enter/exit the block of code. The static variable is allocated at the start of the program and successive calls to the function willnot need to allocate more memory. Same with the thread local variables as long as you reuse the same threads, no?

 

[Ben Bacarisse]

Yes, but memory for the tmp variable in your example is
allocated/deallocated every time you enter/exit the block of code. The
static variable is allocated at the start of the program and
successive calls to the function will not need to allocate more
memory. Same with the thread local variables as long as you reuse the
same threads, no?

It is a rare program that has to worry about the allocation of an
automatic array. The CPU cost is often zero. Since a swap that uses an
auto buffer is entirely portable and is likely as efficient as one that
uses non-portable thread local storage or possibly problematic static
storage, it's the way I'd go every time.

 

[Nelu]

It is a rare program that has to worry about the allocation of an
automatic array. The CPU cost is often zero. Since a swap that uses an
auto buffer is entirely portable and is likely as efficient as one that
uses non-portable thread local storage or possibly problematic static
storage, it's the way I'd go every time.

That makes sense. In the DOS days the stack size was a limiting factor, I think. Is the size of the automatic array subject to implementation or are there minimal requirements imposed by the standard?

 

[James Kuyper]

That makes sense. In the DOS days the stack size was a limiting factor, I think. Is the size of the automatic array subject to implementation or are there minimal requirements imposed by the standard?

The C standard never even mentions the stack, and can be implemented on
machines without a hardware stack. Even on platforms where there is a
stack, the C standard imposes no requirements from which you can infer a
minimum size for that stack.

 

[Ben Bacarisse]

That makes sense. In the DOS days the stack size was a limiting
factor, I think. Is the size of the automatic array subject to
implementation or are there minimal requirements imposed by the
standard?

The standard does not guarantee very much at all about minimum
provision. It's almost impossible to do so -- you'd have to qualify
everything. It can't say that you can always make an array of at least
X bytes, because you might be deeply nested in function calls already.

You make a good point, though. There are cases where resources are very
limited and in these special cases (say some weird embedded system with
very low memory) alternatives are needed (the obvious one being byte by
byte copy until measurement show it to be a bottleneck). So, yes, I
should have said "every time unless there is some environmental reason
to consider alternatives".

 

[Nelu]

The C standard never even mentions the stack, and can be implemented on
machines without a hardware stack. Even on platforms where there is a
stack, the C standard imposes no requirements from which you can infer a
minimum size for that stack.

I know that there is no reference to a stack in the standard. The DOS stackthing was just an example. My question was about the standard and the minimal guarantees for the size of automatic variables. I haven't seen anythingin the draft I have but I thought I may have missed it.

 

[Nelu]

You make a good point, though. There are cases where resources are very
limited and in these special cases (say some weird embedded system with
very low memory) alternatives are needed (the obvious one being byte by
byte copy until measurement show it to be a bottleneck). So, yes, I
should have said "every time unless there is some environmental reason
to consider alternatives".

I was wondering if this was one consideration behind using statically allocated memory for gmtime().

 

[James Kuyper]

I know that there is no reference to a stack in the standard. The DOS stack thing was just an example. My question was about the standard and the minimal guarantees for the size of automatic variables. I haven't seen anything in the draft I have but I thought I may have missed it.

It doesn't. Every implementation of C must include a single program
meeting certain requirements, which it must translate and execute
correctly. A naive examination of those requirements would imply that a
stack based implementation needs to allow sufficient stack space for at
least one call to a function that takes at least 127 arguments. However,
that function call could be written in such a way that it would be
optimized away, so that a much smaller stack would be sufficient. None
of the other limits are applicable.

 

[Nelu]

If you want instead, to have a single memory reservation
for multiple function calls, and also to have thread safety,
then you could copy the technique used for the renentrant
varieties of strtok, commonly available on many systems
and usually known as either strtok_r or strtokr.
You add another parameter to the swap function
with the address of the scratch memory.
The scratch memory is reserved in the calling function
and can have any kind of duration.

Yes, that's what I usually do. Here, I was only considering the function prototype that the OP used.

 

[Nelu]

It doesn't. Every implementation of C must include a single program
meeting certain requirements, which it must translate and execute
correctly. A naive examination of those requirements would imply that a
stack based implementation needs to allow sufficient stack space for at
least one call to a function that takes at least 127 arguments. However,
that function call could be written in such a way that it would be
optimized away, so that a much smaller stack would be sufficient. None
of the other limits are applicable.

Thanks.

 

[Seebs]

I was wondering if this was one consideration behind using
statically allocated memory for gmtime().

Probably not. A lot of functions like that predate threading (no, really!)
and static was an easy way to allow you to return the address of something
without having to alloc it.

-s

 

[Tim Rentsch]

I know that there is no reference to a stack in the standard. The DOS
stack thing was just an example. My question was about the standard
and the minimal guarantees for the size of automatic variables. I
haven't seen anything in the draft I have but I thought I may have
missed it.

It doesn't. Every implementation of C must include a single program
meeting certain requirements, which it must translate and execute
correctly. [snip]

Not exactly right. There must be such a program, but there
is no obligation for the implementation to include it, or
even say anything about it at all.