twitter: comp.lang.c - 25 new messages in 11 topics

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

==============================================================================
TOPIC: Shorter Rot13 Pure-C Implementation
http://groups.google.com/group/comp.lang.c/t/01d6c3202b93f929?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Mar 7 2010 9:54 am
From: Agent Spikes

Hi James,

My compiler actually does show me the warnings, however, I chose to
ignore them as it was against the goal set forth in undertaking this
project: make the "worlds shortest C Implementation of Rot13" even
shorter. (By Pure-C, I mean to say no cheap hacks like exec'ing an
external application like "tr" to do the translation for you.) In
light of this, the warnings and inability to build on some obscure
systems is most definitely a side effect I considered, but in the end,
the small rarity that they are (except for maybe Microsoft compilers,
don't know on that one) was against the goals of the undertaking.

Being that the raw source size (including the final LF) was the
biggest concern of this challenge, I wasn't too worried about speed --
in all reality, the obfuscated and small version posted very likely
can be done quicker with alternate methods, at the cost of a larger
source size.

The variable naming thing is generally something I adhere very
strongly to, but with only one variable, I'm not sure that there would
be much benefit to changing the variable name from Michael Schroeder's
work (after all, I merely made his works even smaller).

In any case, I really do appreciate that you've taken the time to
provide your insights. I generally hate just about every warning in a
"real" project and any code I release other than this has 0 warnings
left in it. (Even though some are fine to leave there -- I'm just a
bit OCD about that.)

Thanks!

Wesley S.

On Mar 7, 7:31 am, James Dow Allen <jdallen2...@yahoo.com> wrote:
> Did you profile your code first to see if greater efficiency
> were needed?
[snip]
> You've failed to include the stdio.h header;
> your definition of main is non-compliant, deprecable,
> and probably guarantees undefined behavior, and main's
> return should be explicit.
>
> We'd better avoid discussing your placement of white
> space (although you did find a clever way to finesse
> the entire issue). My own preference is One True Style,
> but I'll admit to finding your approach superior
> to some alternates espoused in a recent thread.
> We all agree descriptive variable numbers are
> appropriate; I'd have chosen 'b' or perhaps 't'
> over your 'a'.
>
> Finally, your code won't work on Ebcdic machines,
> though that doesn't bother *me*.
> (For my own programming I'm no more interested in
> support for Ebcdic than I am in support for Windows.
> Anyway, some people say that IBM'ers are overly
> sober with no sense of whimsy: do they really use
> rot13?)

== 2 of 2 ==
Date: Sun, Mar 7 2010 11:03 am
From: Ben Bacarisse

Agent Spikes <wesley.spikes@gmail.com> writes:

Interleaved posting is preferred here so I've kept some context and
re-order your post.

> On Mar 7, 7:31 am, James Dow Allen <jdallen2...@yahoo.com> wrote:
>> You've failed to include the stdio.h header;
>> your definition of main is non-compliant, deprecable,
>> and probably guarantees undefined behavior, and main's
>> return should be explicit.
<snip>
>> Finally, your code won't work on Ebcdic machines,
<snip joke>
>
> My compiler actually does show me the warnings, however, I chose to
> ignore them as it was against the goal set forth in undertaking this
> project: make the "worlds shortest C Implementation of Rot13" even
> shorter. (By Pure-C, I mean to say no cheap hacks like exec'ing an
> external application like "tr" to do the translation for you.)

So the rules seem to be that you can't use anything other than
standard C but you don't have to use standard C.

| main(a){while(a=getchar())putchar(a-1/((a&~32)/13*2-11)*13);}

It would seem that the program does not even have to terminate. Are
there any formal conditions the program must meet?

<snip>
--
Ben.

==============================================================================
TOPIC: how to get out of double for loops?
http://groups.google.com/group/comp.lang.c/t/535cb24e8f02aec3?hl=en
==============================================================================

== 1 of 4 ==
Date: Sun, Mar 7 2010 9:58 am
From: ram@zedat.fu-berlin.de (Stefan Ram)

cri@tiac.net (Richard Harter) writes:
>In some languages, not C of course, you can escape (break) from a
>simple delimited block. If you could do this in C you could
>write:
> {
> if ((result = something()) == BAD) break;
> if ((result = somethingelse()) == BAD) break;
> }
>
> if (result == BAD) {

if
( ( result = something() ) == BAD )||
( result = somethingelse() )== BAD ))
{

== 2 of 4 ==
Date: Sun, Mar 7 2010 10:53 am
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <4n1b67-33b.ln1@jones.homeip.net>, lawrence.jones@siemens.com writes:
> Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
>>
>> Yes (most of the time). They should have stakes driven
>> through their hearts -- but as has been pointed out here oft
>> and again, the C language itself doesn't use a stake ...
>
> You keep making puns like that and you're going to be in a heap of
> trouble.

Care to explain what "use a stake" means here? I tried to look it up,
with not much success.

Thanks,
lacos

== 3 of 4 ==
Date: Sun, Mar 7 2010 11:14 am
From: Ben Bacarisse

lacos@ludens.elte.hu (Ersek, Laszlo) writes:

> In article <4n1b67-33b.ln1@jones.homeip.net>, lawrence.jones@siemens.com writes:
>> Eric Sosman <esosman@ieee-dot-org.invalid> wrote:
>>>
>>> Yes (most of the time). They should have stakes driven
>>> through their hearts -- but as has been pointed out here oft
>>> and again, the C language itself doesn't use a stake ...
>>
>> You keep making puns like that and you're going to be in a heap of
>> trouble.
>
> Care to explain what "use a stake" means here? I tried to look it up,
> with not much success.

It's a pun. Eric is playing on the oft quoted phrase "C does not use
a stack". Hence Lawrence's "heap" pun in reply.

Eric's did register on my humour meter but Lawrence is talking a load
of mallocs.

--
Ben.

== 4 of 4 ==
Date: Sun, Mar 7 2010 12:06 pm
From: James Harris

On 7 Mar, 14:16, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
...
> In a language (or programming style) without break and goto one can
> make strong arguments about the behaviour of loops. After
>
> while (E) { S; }
>
> one can assert that !E is true (there may not be an "after" of
> course).

(As you know) that's not much of a deduction. So what advantage can
similar reasoning be expected to give in imperative programming? (Not
functional programming which is another matter.) I've seen people
write about advantages of certain control structures but I've never
come across an explanation of the principles, if there are any.

For example the most general imperative loop construct would be of the
form

for (;;) {
<code>
if (c1) break;
<more code>
if (c2) break;
<even more code>
if (c3) break;
<etc>
}

Top and bottom decision loops as well as arbitrary mid decisions can
all be expressed using such a control structure. Is there something
about that form which inhibits reasoning?

> Banning continue and non-terminal return statements also
> simplifies the reasoning about the interaction of S and E.

I'm glad to hear it but in what way or ways does *continue* work
against reasoning?

I guess you are referring to mid-routine return statements. They can
return no value or a value of the wrong type. Any other problems with
them from the point of view of reasoning?

James

==============================================================================
TOPIC: click me
http://groups.google.com/group/comp.lang.c/t/2e218d3194bd9a39?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Mar 7 2010 10:12 am
From: madhan

please clic it it will be usefull to you

http://123maza.com/78/healthyfitness/

==============================================================================
TOPIC: Mommy, Where Do Standards Come From?
http://groups.google.com/group/comp.lang.c/t/2ee9317b397797a0?hl=en
==============================================================================

== 1 of 4 ==
Date: Sun, Mar 7 2010 10:12 am
From: Lorenzo Villari

On Sat, 06 Mar 2010 19:10:24 -0800
Keith Thompson <kst-u@mib.org> wrote:

>
> I don't know what you're referring to. I have copies if n1256.pdf
> (which incorporates C99 plus the three Technical Corrigenda) and
> n1425.pdf (which is the latest pre-C201X committee draft), both of
> which are available on the Committee's web site. I don't have,
> or have access to, anything newer that's not generally available.
>

I wondered What do you think about this:

http://www.knosof.co.uk/cbook/cbook.html

== 2 of 4 ==
Date: Sun, Mar 7 2010 10:50 am
From: Walter Banks

Lorenzo Villari wrote:

> On Sat, 06 Mar 2010 19:10:24 -0800
> Keith Thompson <kst-u@mib.org> wrote:
>
> >
> > I don't know what you're referring to. I have copies if n1256.pdf
> > (which incorporates C99 plus the three Technical Corrigenda) and
> > n1425.pdf (which is the latest pre-C201X committee draft), both of
> > which are available on the Committee's web site. I don't have,
> > or have access to, anything newer that's not generally available.
> >
>
> I wondered What do you think about this:
>
> http://www.knosof.co.uk/cbook/cbook.html

It is worth reading. It is a very detailed commentary on C99 with
some changes since then. It often is a good reference to look at the
intent of the C99 standard from one persons perspective. Some of
the comments are provocative others have detailed explanations.

w..

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

== 3 of 4 ==
Date: Sun, Mar 7 2010 11:02 am
From: Lorenzo Villari

On Sun, 07 Mar 2010 13:50:43 -0500
Walter Banks <walter@bytecraft.com> wrote:

>
>
> Lorenzo Villari wrote:
>
> > On Sat, 06 Mar 2010 19:10:24 -0800
> > Keith Thompson <kst-u@mib.org> wrote:
> >
> > >
> > > I don't know what you're referring to. I have copies if n1256.pdf
> > > (which incorporates C99 plus the three Technical Corrigenda) and
> > > n1425.pdf (which is the latest pre-C201X committee draft), both of
> > > which are available on the Committee's web site. I don't have,
> > > or have access to, anything newer that's not generally available.
> > >
> >
> > I wondered What do you think about this:
> >
> > http://www.knosof.co.uk/cbook/cbook.html
>
> It is worth reading. It is a very detailed commentary on C99 with
> some changes since then. It often is a good reference to look at the
> intent of the C99 standard from one persons perspective. Some of
> the comments are provocative others have detailed explanations.
>

Oh good to know that. Thank you for your opinion. It's huge but
interesting.

== 4 of 4 ==
Date: Sun, Mar 7 2010 11:57 am
From: Keith Thompson

Lorenzo Villari <vlllnz@tiscali.it> writes:
> On Sat, 06 Mar 2010 19:10:24 -0800
> Keith Thompson <kst-u@mib.org> wrote:
>
>>
>> I don't know what you're referring to. I have copies if n1256.pdf
>> (which incorporates C99 plus the three Technical Corrigenda) and
>> n1425.pdf (which is the latest pre-C201X committee draft), both of
>> which are available on the Committee's web site. I don't have,
>> or have access to, anything newer that's not generally available.
>>
>
> I wondered What do you think about this:
>
> http://www.knosof.co.uk/cbook/cbook.html

I'm not sure why you're asking me in particular -- or was your
question intended for the newsgroup generally?

It's big book, and I certainly haven't had time to read it. I like
the idea of a commentary on the standard. A couple of things did
jump out at me in a few minutes.

I think the author misuses the word "sentence". For example, "At
some point you ought to read all of sentence 0 (the introduction)."

And the title "The New C Standard", in a book updated in 2009,
implies that could be about 201X; I had to skim through several
pages of introductory material to discover that it only discusses
C99 and earlier standards.

These are fairly trivial criticisms, and do not necessarily say
anything about the general quality of the book.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

==============================================================================
TOPIC: Fixed Point implementation of C exponent function
http://groups.google.com/group/comp.lang.c/t/6a48a091262633a2?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Mar 7 2010 10:28 am
From: "BGB / cr88192"

"banu" <varun.nagpaal@gmail.com> wrote in message
news:2f14e97c-fc22-4fdc-abb1-b897b7731171@15g2000yqi.googlegroups.com...
> Hi,
> I tried to google a lot searching for fixed point implementation of
> exponent function y = exp(x) (e to the power x) but could not find it.
> Also I think there is no post on this group also. I found some CORDIC
> implementations but those were in C++. I need lightweight
> implementation in C.
>
> I want to use this function in an image processing algorithm to be
> implemented on a VLIW-DSP which doesn't have a floating point unit.
>
> I will appreciate in anyone here can suggest a plain C - code which
> handles both positive and negative arguments (x<0 and x<=0) ,with
> reasonable accuracy and performance.
>

well, as others have noted, it depends a lot on the number of bits in the
integer and fractional parts.

one possible idea that comes to mind is this:
rebase the exponent into 2^x form (this involves multiplying x by a constant
of 1/ln(2) or about 1.4426950...).

this way, a base can be calculated which is simply an integer power of 2.

then, one only need calculate a scale based on the fractional part, and if
the number of fractional bits is sufficiently small (or memory sufficiently
large), then a lookup table can be used.

then, the 2 numbers can be multiplied together, and one is done.

granted, for larger exponents this strategy may become less accurate. could
be addressed by using a bigger lookup table, or by using a recursive
strategy to calculate the fraction. similarly, some recursion could also
allow a smaller table at the cost of some speed.

another had mentioned using the taylor series, which is also an option, but
not likely as fast as using a lookup table.

for example (hypothetical):
#define FIX12_INVLN2 5909 //1.442695, 12-bit fraction
#define FIX28_INVLN2 387270501 //1.442695, 28-bit fraction

typedef int32_t fix12;
typedef int32_t fix28;

fix12 fix12_mul(fix12 a, fix12 b)
{
return ((fix12)((((int64_t)a)*b)>>12));
}

fix12 fix12_mul28(fix12 a, fix28 b)
{
return ((fix12)((((int64_t)a)*b)>>28));
}

static fix28 fix12_exp2lut[4096]={...}; //takes ~16kB memory

fix12 fix12_exp2(fix12 x)
{
fix12 b, f;
b=1<<(12+(x>>12)); //calculate base
f=fix12_exp2lut[x&4095];
return(fix12_mul28(b, f));
}

fix12 fix12_exp(fix12 x)
{ return(fix12_exp2(fix12_mul28(x, FIX28_INVLN2))); }

note:
some of the usual optimizations for optimizing fixed point calculations (or
improving accuracy) could possibly also be used here.

> thanks
> varun

==============================================================================
TOPIC: Stylistic questions on UNIX C coding.
http://groups.google.com/group/comp.lang.c/t/51d2b24a60d73f18?hl=en
==============================================================================

== 1 of 3 ==
Date: Sun, Mar 7 2010 10:46 am
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <0.8e8fb4cfddc834871af3.20100307151405GMT.87hbos6u6a.fsf@bsb.me.uk>, Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>> pete <pfiland@mindspring.com> writes:
>>>>
>>>> [...]
>>>>
>>>>> To count down through an array with N elements, I use
>>>>>
>>>>> size_t i = N;
>>>>>
>>>>> while (i-- != 0) {
>>>>> array[i];
>>>>> }
>>>>
>>>> And you excuse for writing confusing code which requests that the
>>>> machine does useless things is that software to work around you has
>>>> already been developed, right?
>>>
>>> Why not show everyone what you consider to be the right way to do this
>>> so that we can all have the chance to write better/clearer loops? Not
>>> everyone will agree, of course, but it is surely better to give
>>> examples of good code than to criticise code you don't like.
>>
>> Isn't this obvious? As written above, the calculation oversteps,
>> because the postdecrement will return zero when i already had this
>> value before decrementing it again.
>
> What do you mean by "oversteps"? The code above works correctly when
> N is zero and it executes the body exactly N times as it should.

Yes, but after that, "i" ends up as (size_t)-1. Compare:

size_t i = N;

while (0u < i) {
--i;

array[i];
array[i];
array[i];
}

Cheers,
lacos

== 2 of 3 ==
Date: Sun, Mar 7 2010 11:23 am
From: Ben Bacarisse

lacos@ludens.elte.hu (Ersek, Laszlo) writes:

> In article <0.8e8fb4cfddc834871af3.20100307151405GMT.87hbos6u6a.fsf@bsb.me.uk>, Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>>> pete <pfiland@mindspring.com> writes:
>>>>>
>>>>> [...]
>>>>>
>>>>>> To count down through an array with N elements, I use
>>>>>>
>>>>>> size_t i = N;
>>>>>>
>>>>>> while (i-- != 0) {
>>>>>> array[i];
>>>>>> }
>>>>>
>>>>> And you excuse for writing confusing code which requests that the
>>>>> machine does useless things is that software to work around you has
>>>>> already been developed, right?
>>>>
>>>> Why not show everyone what you consider to be the right way to do this
>>>> so that we can all have the chance to write better/clearer loops? Not
>>>> everyone will agree, of course, but it is surely better to give
>>>> examples of good code than to criticise code you don't like.
>>>
>>> Isn't this obvious? As written above, the calculation oversteps,
>>> because the postdecrement will return zero when i already had this
>>> value before decrementing it again.
>>
>> What do you mean by "oversteps"? The code above works correctly when
>> N is zero and it executes the body exactly N times as it should.
>
> Yes, but after that, "i" ends up as (size_t)-1.

That's why I asked -- just in case this what his complaint. It's not
one I'd worry about. In fact in some situations this is an advantage:

> Compare:
>
> size_t i = N;
>
> while (0u < i) {
> --i;
>
> array[i];
> array[i];
> array[i];
> }

If the loop body changes so that is includes some break statements,
pete's loop makes normal and abnormal loop exit easy to distinguish.
It's not a big deal, but I do prefer pete's formulation for this
reason.

--
Ben.

== 3 of 3 ==
Date: Sun, Mar 7 2010 11:22 am
From: Keith Thompson

Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>> pete <pfiland@mindspring.com> writes:
>>>
>>> [...]
>>>
>>>> To count down through an array with N elements, I use
>>>>
>>>> size_t i = N;
>>>>
>>>> while (i-- != 0) {
>>>> array[i];
>>>> }
>>>
>>> And you excuse for writing confusing code which requests that the
>>> machine does useless things is that software to work around you has
>>> already been developed, right?
>>
>> Why not show everyone what you consider to be the right way to do this
>> so that we can all have the chance to write better/clearer loops? Not
>> everyone will agree, of course, but it is surely better to give
>> examples of good code than to criticise code you don't like.
>
> Isn't this obvious?

No -- or at least it's not nearly as obvious as you seem to think
it is.

> As written above, the calculation oversteps,
> because the postdecrement will return zero when i already had this
> value before decrementing it again.

It does, but I don't think this is a significant problem. The most
common form of loop for iterating *up* through an array is:

for (i = 0; i < N; i ++) [
... array[i] ...
}

oversteps the upper bound of the array.

> Also, the condition is known to be
> true so checking it before the first execution of the loop body is a
> pointless exercise.

That's true *only* if you know that you're iteratingover the entire
array. What if N, rather than being the total number of elements in
the array, is the number of elements that you're current interested
in? (Say you're working with a counted string implementation.)
Then N could easily be 0.

> A sensible way to express this in C would be
>
> do array[--i]; while (i);

This fails rather catastrophically when N is 0.

Do you use a different form of loop when N can be 0 vs. when you know
it can't? If not, can you show us a loop that (a) iterates from
size_t values N-1 down to 0, (b) is as efficient as pete's loop,
and (c) is as clear to the reader as pete's loop?

> This is politically incorrect for various reasons not the least one of
> which is that people are often proud of having written code
> thoughtlessly, presumably, because this demonstrate that it is below
> their dignity to care for something as miniscule as that, and which
> one will end up generating better code depends on the compiler and how
> it was used. Eg, I have reason to suspect that at least some versions
> of gcc transformate all loops to the 'condition in front of it'-form
> (I don't know the English term for this, the German one would be
> 'abweisende Schleife') before they are feed to the various weird loop
> optimizers intended to turn thoughtlessly written FORTRAN into
> sensible machine code.

There's a good reason for that. Very often a while or for loop
is the clearest way to express some algorithm. The body of the
loop might not be executed at all. So an optimizing compiler might
transform this:

while (condition) {
something;
}

to the equivalent of this:

if (condition) {
/* ... */
do {
something;
while condition;
}

Everything within the body of the loop is executed N times, for
some N >= 0. If some of that code is loop-invariant, it can be
executed just once -- but if N is 0, it shouldn't be executed
at all. Loop-invariant code can be "hoisted" outside the loop.
The purpose of the transformation is to provide a place (marked
/* ... */) to which any loop-invariant code can be hoisted.

This *doesn't* imply that the programmer should have written the
if/do while version of the code in the first place. The while loop
is generally clearer to the reader than the transformed version,
and easier to maintain since the condition is only written once.
It requires the optimizer to do a tiny amount of extra work, but
that's its job.

[snip]

Our fundamental point of disagreement is that you seem to think
that pete's loop:

size_t i = N;

while (i-- != 0) {
array[i];
}

is not merely bad, but obviously bad, whereas I see nothing wrong
with it. The initial test is superfluous only if we know that N
> 0; I don't think leaving it in place is a significant problem,
worth restructuring the code. i is incremented again at the end,
leaving it with a value if SIZE_MAX after the loop; again, I don't
think that's a significant problem.

Indeed, if C had a higher-level loop construct for iterating over a
range of values:

for i in reverse 0 .. N-1 loop
...
end loop;

(that's Ada syntax), the compiler might well generate exactly the
same code as it does for pete's loop.

==============================================================================
TOPIC: UTF-8 and wchar_t
http://groups.google.com/group/comp.lang.c/t/6e69f9f50e29243f?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Mar 7 2010 11:32 am
From: "christian.bau"

That code isn't filtering out 3 and 4 byte sequences that could be
represented in a shorter way, which is one major cause of software
vulnerabilities, and it doesn't filter values > 0x10ffff if WCHAR_MAX
is large (like 32 bit). And I'm not quite sure why you compare against
WCHAR_MAX - WCHAR_MIN.

== 2 of 2 ==
Date: Sun, Mar 7 2010 11:35 am
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <87sk8cic2w.fsf@erwin.mina86.com>,
Michal Nazarewicz <mina86@tlen.pl> writes:

> static void _out(wchar_t ch) {
> char buf[MB_CUR_MAX];
> int ret;
>
> retry:
> ret = wctomb(buf, ch);
> if (ret > 0) {
> printf("%.*s", ret, buf);
> } else if (ch != L'?') {
> ch = L'?';
> goto retry;
> } else {
> putchar('?');
> }
> }

L'?' can always be represented in the execution character set. '?' is a
member of both the source and the execution basic character set (C99
5.2.1.2p1, 6.4.4.4p11, 7.17p2). Thus if wctomb() fails above,

ch != L'?'

will always hold. What's more, you don't need to convert L'?' with an
explicit call to wctomb(), since it will store a single '?' character
anyway. The members of the basic character sets are locale-independent.

Hence, the middle section and the label are superfluous.

(I didn't look at other parts of your code.)

Cheers,
lacos

==============================================================================
TOPIC: An interview question
http://groups.google.com/group/comp.lang.c/t/c93105672f793e63?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Mar 7 2010 11:39 am
From: Keith Thompson

Moi <root@invalid.address.org> writes:
> On Sat, 06 Mar 2010 18:56:00 -0800, Keith Thompson wrote:
>
>> Tim Rentsch <txr@x-alumni2.alumni.caltech.edu> writes:
>>> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>>>> On 3/6/2010 9:48 AM, Tim Rentsch wrote:
>>>>> Eric Sosman<esosman@ieee-dot-org.invalid> writes:
>>
>>
>> I think that, if you happen to know that size_t is a typedef for, say,
>> unsigned long on a given implementation, you can safely declare
>>
>> void *malloc(unsigned long size);
>>
>> and call it with no risk of UB *for that implementation*. If size_t is
>> declared as
>>
>> typedef unsigned long size_t;
>>
>
> IMHO the sizeof operator evaluates to a size_t, or at least
> to a unsigned type that is compatible with a size_t.

"IMHO"? This isn't a matter of opinion; the standard says that sizeof
yields a size_t result. C99 6.5.3.4p4:

The value of the result is implementation-defined, and its type
(an unsigned integer type) is size_t, defined in <stddef.h>
(and other headers).

> So basically you could use the "sizeof expression" syntax:
>
> unsigned sizeofsizeof;
>
> sizeofsizeof = sizeof sizeof 0+0;

Ben already covered this. "sizeof sizeof 0" is a simpler way to
get the size of size_t ("sizeof(size_t) is even simpler, but we're
assuming that we're not allowed to #include standard headers).
But knowing the size of size_t doesn't tell you its type.

Given the original (rather silly) problem statement, size_t isn't even
an issue. The standard's synopsis for strftime() is:

#include <time.h>
size_t strftime(char * restrict s,
size_t maxsize,
const char * restrict format,
const struct tm * restrict timeptr);

and the interviewer assumed that you could savely redeclare "struct
tm" by hand, without reference to the implementation's <time.h>.
Given this assumption, you could safely pass "sizeof s" as the second
argument, where s is the target array. Handling (even ignoring)
the result is still a problem, but I suspect that's just something
the interviewer hadn't thought of.

Or the interviewer is more clever than most of us have assumed,
and the point of the question was to elicit these objections.

== 2 of 2 ==
Date: Sun, Mar 7 2010 12:26 pm
From: Moi

On Sun, 07 Mar 2010 13:38:43 +0000, Ben Bacarisse wrote:

> Moi <root@invalid.address.org> writes:
>
>> On Sat, 06 Mar 2010 18:56:00 -0800, Keith Thompson wrote:
>>
>>> Tim Rentsch <txr@x-alumni2.alumni.caltech.edu> writes:
>>>> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>>>>> On 3/6/2010 9:48 AM, Tim Rentsch wrote:
>>>>>> Eric Sosman<esosman@ieee-dot-org.invalid> writes:
>>>
>>>

>>>
>> IMHO the sizeof operator evaluates to a size_t, or at least to a
>> unsigned type that is compatible with a size_t.
>>
>> So basically you could use the "sizeof expression" syntax:
>>
>> unsigned sizeofsizeof;
>>
>> sizeofsizeof = sizeof sizeof 0+0;
>
> Did you mean that? It parses as (sizeof (sizeof 0)) + 0. What is the
> 0+0 for?
>

To catch your attention. The essence is that sizeof yields a size_t
*even if size_t has not been typedeffed yet*

> I can't see how knowing the size of a size_t helps here. Calling a
> function with the wrong type of argument is UB even if the size of the
> argument is correct. In practical terms, getting the size right (for an
> integer argument) is often the thing that matters so I suppose that
> might have been part of the intent of the question.

Knowing the size could be useful to create fake function declarations for
malloc() or strlen().

unsigned long long mystrlen(const char *str)
{

if (sizeofsizeof == sizeof (unsigned long)) {
unsigned long long strlen(char const *str);
return strlen (str);
}
else if (sizeof sizeof == sizeof (unsigned long)) {

unsigned long strlen(char const *str);
return strlen(str);
}
else ...
}

This enables one to perform the call without size_t typedeffed.
(which of course is silly, just as the interview question
was silly in the first place)

==============================================================================
TOPIC: problem 1.13 The C programming language
http://groups.google.com/group/comp.lang.c/t/e3b5a2688181479c?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Mar 7 2010 11:46 am
From: joag

I'll try the next week to update the program with your suggestions, I
also added a topic on my page www.nixheiser.org (guides - problem 1.13
section) so other people can reach the same topic and comment about it
there because there is a little forum for comments; in the rest of the
month I'll try to do what follows in the book (The C programming
language by K&R). I've been told by other people to start with this
book and I never did this and now I see why people recommend it, it is
great ^n book.

joag

==============================================================================
TOPIC: Has thought been given given to a cleaned up C? Possibly called C+.
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en
==============================================================================

== 1 of 4 ==
Date: Sun, Mar 7 2010 12:24 pm
From: jacob navia

Thomas Richter a écrit :
> jacob navia wrote:
>> o The library is an unchanged copy of the C library of 1980. Using
>> the same software today after 30 years of development (and what a
>> development) in this field is plain nonsense.
>
> Given the amount of existing code that builds on the existing C library,
> replacing it is actually plain nonsense.
>

Nobody is proposing that. This is an old trick in this discussions. Any
improvement to C is impossible because the old code. That is plainly not
true. The old code and the associated functions can be kept, but C
should be able to use BUFFERS of KNOWN length, avoiding the most common
cause of buffer overflows. Let's be explicit:

typedef struct {size_t length; char data[];} Buffer;

memset can be done as "Memset", for instance like this
bool Memset(Buffer *dest, int char_val);

where:
The result is zero if buffer is NULL, 1 if buffer is not null.

This is an easy example. Strcpy is just as trivial, but with a character
buffer.

Giving a similar but different name easies the porting and is compatible
with old code.

Why argument with flawed arguments? I DID tell jun my message that I
renamed the string functions Strcpy for instance. Why arguing that I
`want to "replace" strcpy"? Of course I want to replace the
functionality, making it less error prone, but not the function.

>> Many proposals have
>> been done to update the C library, specifically to correct the obvious
>> lack of security and error handling. Yes, the committee got rid of
>> gets() (could have been done in 1999) and acknowledged the buffer
>> overflow in the asctime() code, but still, there are a LOT of
>> functions in the standard library, specially the string handling
>> functions that are plainly WRONG...
>
> I don't think they're wrong. They require care, care some people forgot.

This has been discussed and discussed, and the essential point is that
if somebody makes a mistaken once, it is his/her fault. Ifvthousands of
programmers make always the same errors it is the tool's fault. In this
group, r Heathfield, an experienced C programmer had to acknowledge
that his published code had a BUG in his code handling string data.

And Mr Heathfield has been somebody that ALWAYS sys exactly the same as
you now. "You have to be careful" etc. But he himself was proved wrong.

I am sure you can be proved wrong too.

> As for example checking for the proper buffer size. A "strcpy" can be
> absolutely correct if you have control on the size of the input string,
> and it can be completely fatal if not.

Exactly. A better version would use COUNTED buffers!

> If you want to avoid the hassle,
> go for C++, or use the limiting functions.

Here we have it again. Any development of C is always answered with
"Go to C++" even by committee members. C should remain full of warts
so that C++ can be seen as the only alternative. There should be NO
simpler language than C++, all development of C as a language should
STOP.

You are confirming what I say about committee members.

{snip}

>
>> o There is no standard way of making a list/a tree/ a flexible array/
>> in C. Everything must be ported, recompiled, etc. I am working in
>> a proposalfor this, but apparently the committee will decide a
>> feature freeze next meeting, so I will have to wait till 2020
>> at least.
>
> Why should there? C is a very small language, and I really don't see the
> need for such simple data structures in the standard.

Then, each C programmer needs to port a library that does lists,
flexible arrays, or find and debug one and port it, etc.

> If you need
> library support for that, and a richer structure that helps you with
> such containers, use C++ and the STL.

OF COURSE that is the solution. Yu are (again) confirming what I said:
All development in C should stop and we should swallow C++ if we want to
do the simplest tasks!

If we want to use (portably) a list, we are forced to use C++ and
their STL...

> This is what it has been designed
> for.
>

C is still being used, and many important projects are based on it. My
thesis is that a simple language is necessary and useful. Adding
a general and extensible container interface for C doesn't change at all
the language but gives C programmer the advantages of not having to
program the same data structures over and over.

The proliferation of libraries that do the same thing WITHOUT a standard
in C means that each big project in C has several versions of the same
data structure because library XYZ uses lists with the "Next" field
in the fiorst position and library"XXX" uses a list with Next in the
second position. Besides all APIs are different, etc.

This is SO OBVIOUS that doesn't even need to be discussed. But C should
be kept in its present state so taht the only alternative is to swallow
C++

Well, you confirm everything that I said.
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 2 of 4 ==
Date: Sun, Mar 7 2010 12:25 pm
From: Nick Keighley

On 6 Mar, 19:17, jacob navia <ja...@spamsink.net> wrote:
> Rob Kendrick a écrit :
>
> > On Fri, 5 Mar 2010 15:52:17 -0600 (CST)
> > Ian Collins <ian-n...@hotmail.com> wrote:
>
> >> So it enhances rather than attempting to clean up the grubby corners
> >> of the language. C++ suffers the same baggage - compatible with
> >> standard C.
>
> > Of course, C++ isn't compatible with standard C. If you think it is,
> > try giving this to a C++ compiler:
>
> > int foo(void) { auto new = 0; return new; }
>
> `Well, to deduce from this that C and C++ are "not compatible" is just
> nonsense.
>
> Yes, C++ has new (pun intended) keywords. If you avoid those
> pitfalls they are compatible. Yes, there are other minor details
> like that but I have never found a show stopper.

quite correct. This harping on about keywords is just silly. You can
write code that compiles with both and a C compiler and a C++
compiler. And it isn't that hard.
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 3 of 4 ==
Date: Sun, Mar 7 2010 12:26 pm
From: "bartc"

"Casey Hawthorne" <caseyhHAMMER_TIME@istar.ca> wrote in message
news:clcm-20100305-0006@plethora.net...
> Peter Van Der Linden in "Expert C Programming - Deep C Secrets" 1994
> and I imagine others have pointed out some of C's idiosyncrasies.
> Has thought been given given to a cleaned up C? Possibly called C+.

That's exactly what I was thinking, when I first looked at using C around
'92**. Surely someone would have got round to tidying up the language by
then?

But people who use C seem to love it exactly the way it is.

And I'd imagine any replacement language created now, especially by
committee. would have it's own difficulties.

(** As it happened, I chose to develop my own language instead (it was
easier...). Creating a language that does pretty much what C does, is not
that difficult, more of a student exercise. However you then have to work
with something that is not mainstream and not compatible with anything else.
And that needs maintaining.)

--
Bartc
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 4 of 4 ==
Date: Sun, Mar 7 2010 12:26 pm
From: cri@tiac.net (Richard Harter)

On Sat, 6 Mar 2010 13:14:48 -0600 (CST), Marco
<prenom_nomus@yahoo.com> wrote:

>On Mar 5, 5:00=A0pm, c...@tiac.net (Richard Harter) wrote:
>> On Fri, 5 Mar 2010 15:32:23 -0600 (CST), Julienne Walker
>
>> >The most recent attempt at taking what C is good at and removing what
>> >it's bad at is called Go.
>>
>> Unfortunately it has serious flaws along with the virtues.
>
> Could you expound upon those flaws - better to use comp.lang.misc
>for that topic

I can and will, but it may be a few days. My major complaint
would be with their approach to concurrency.

Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
It's not much to ask of the universe that it be fair;
it's not much to ask but it just doesn't happen.
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

==============================================================================
TOPIC: Got stuck with quicksort code from the "Unleashed C".
http://groups.google.com/group/comp.lang.c/t/0fb91f93b991c210?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Mar 7 2010 12:29 pm
From: grishin-mailing-lists@minselhoz.samara.ru

Thanks for the replies, guys.

No, It's not a coursework, I've graduated 5 years ago. Just taking
some disciplines for myself (and on my own).
I thought that it's possible to get feedback from [one of] the
author[s] of the book. 10 years have past since publication. I'm
unlikely the first who found the bug (IS it a bug or typographical
error or peculiarities of Russian edition?).
Well, I'm able to trace programs, BTW thank you for fprintf trick.
I've had few crashes before and noticed a weird printf behavior.

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Sunday, March 7, 2010

comp.lang.c - 25 new messages in 11 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts