comp.lang.c - 13 new messages in 7 topics - digest

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

comp.lang.c@googlegroups.com

Today's topics:

* plain int and signed int - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/d3218d3d4e56ae68?hl=en
* arithmetic on a void * pointer - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/451b17d19dcc5236?hl=en
* Style guides for C and/or C++ - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/8ac1309e95a1004a?hl=en
* Aborting - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/ee63c59395130481?hl=en
* stack smashing - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/0de180646e819463?hl=en
* A seg fault - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/29205dee12daebeb?hl=en
* Shorten this popcount and tesbed - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/44cf66dcae62c3f5?hl=en

==============================================================================
TOPIC: plain int and signed int
http://groups.google.com/group/comp.lang.c/t/d3218d3d4e56ae68?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jan 18 2010 7:37 pm
From: Joe Wright

Peter Nilsson wrote:
> Squeamizh <sque...@hotmail.com> wrote:
>> Phil Carmody <thefatphil_demun...@yahoo.co.uk> wrote:
>>> Joe Wright <joewwri...@comcast.net> writes:
>>>> Phil Carmody wrote:
>>>>> Joe Wright <joewwri...@comcast.net> writes:
> [...]
>>>>>> No. (-0) is counter-intuitive to me. I learned two's
>>>>>> complement in 1963 and have never encountered an actual
>>>>>> machine which used anything else. I also learned one's
>>>>>> complement and signed-magnitude at the same time but
>>>>>> have never seen them used in practice.
>>>>> So you've never encountered any floating point numbers,
>>>>> then?
>>>> Is that supposed to be clever? You lose. In C (-0) is
>>>> integral, not floating point. Perhaps you mean (-0.0)?
>>>> Subject: plain int and signed int, not float.
>
> I do recall someone mentioning (or theorising) about a machine
> that only had a floating point unit that implemented integers
> using a non-normalised representation. The exponent would simply
> be padding bits. (...and UINT_MAX would equal INT_MAX.)
>
>>> You were talking about the methods of representation, not the
>>> applications. The representation (having a sign bit which
>>> represents nothing but the sign, and does not affect the
>>> absolute value) is used in floating point units.
>> Read again. He said he's never seen one's complement or sign-
>> magnitude in the real world. That has nothing to do with
>> floating point.
>
> Neither of you can recognise, let alone acknowledge, the
> similarity between sign-mantissa and exponent-sign-mantissa?
>
What? You mean sign-exponent-mantissa maybe.

> If Joe's ever written -1 on a piece of paper, then he has
> seen sign-magnitude in the real world, even if he's never
> seen it implemented for integers on a cpu.
>
Silly.

> But from what I read, people are still designing the odd DSP
> chip to use sign-magnitude integers.
>
Really? I am not familiar with DSP's at all. But I am curious. Why would a
chip designer, knowing all three, choose sign-magnitude or one's complement
over two's complement for fundamental integer math?

> --
> Peter

--
Joe Wright
"If you rob Peter to pay Paul you can depend on the support of Paul."

== 2 of 2 ==
Date: Mon, Jan 18 2010 8:11 pm
From: Squeamizh

On Jan 18, 6:28 pm, Peter Nilsson <ai...@acay.com.au> wrote:
> Squeamizh <sque...@hotmail.com> wrote:
> > Phil Carmody <thefatphil_demun...@yahoo.co.uk> wrote:
> > > Joe Wright <joewwri...@comcast.net> writes:
> > > > Phil Carmody wrote:
> > > >> Joe Wright <joewwri...@comcast.net> writes:
> [...]
> > > >>> No. (-0) is counter-intuitive to me. I learned two's
> > > >>> complement in 1963 and have never encountered an actual
> > > >>> machine which used anything else. I also learned one's
> > > >>> complement and signed-magnitude at the same time but
> > > >>> have never seen them used in practice.
>
> > > >> So you've never encountered any floating point numbers,
> > > >> then?
>
> > > > Is that supposed to be clever? You lose. In C (-0) is
> > > > integral, not floating point. Perhaps you mean (-0.0)?
> > > > Subject: plain int and signed int, not float.
>
> I do recall someone mentioning (or theorising) about a machine
> that only had a floating point unit that implemented integers
> using a non-normalised representation. The exponent would simply
> be padding bits. (...and UINT_MAX would equal INT_MAX.)
>
> > > You were talking about the methods of representation, not the
> > > applications. The representation (having a sign bit which
> > > represents nothing but the sign, and does not affect the
> > > absolute value) is used in floating point units.
>
> > Read again. He said he's never seen one's complement or sign-
> > magnitude in the real world. That has nothing to do with
> > floating point.
>
> Neither of you can recognise, let alone acknowledge, the
> similarity between sign-mantissa and exponent-sign-mantissa?
>
> If Joe's ever written -1 on a piece of paper, then he has
> seen sign-magnitude in the real world, even if he's never
> seen it implemented for integers on a cpu.

This might come as a shock to you (please brace yourself) - a CPU does
not contain a little man with a pencil and paper.

==============================================================================
TOPIC: arithmetic on a void * pointer
http://groups.google.com/group/comp.lang.c/t/451b17d19dcc5236?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 18 2010 8:18 pm
From: spinoza1111

On Jan 15, 3:29 am, Flash Gordon <s...@spam.causeway.com> wrote:
> Gareth Owen wrote:
> > gaze...@shell.xmission.com (Kenny McCormack) writes:
>
> >> In article <87d41e4i39....@gmail.com>, Gareth Owen  <gwo...@gmail.com> wrote:
> >>> Flash Gordon <s...@spam.causeway.com> writes:
>
> >>>>> Say what? As far as I'm aware, all of those you mentioned (except Han)
> >>>>> post under our real names.
> >>>> <snip>
>
> >>>> So your real name is Antonius Twink?
> >>> He counts under "Han From China"
> >> I assume the irony of "Flash Gordon" complaining about people not
> >> posting under their real names has escaped no one...?
>
> I was not complaining.
>
> Richard Heathfield listed a number of posters, and Antonius Twink
> claimed that the only poster in the list not posting under his/her real
> name was Han. That was a factually incorrect claim since Antonius Twink
> was on the list and that is not his real name.
>
> > Including Flash himself, who explicitly mentioned it in his post to
> > which yours is an antecedent.
>
> I also pointed out that it is easy to find out what my real name is.
>
> > Still, often, pseudonyms are handy.  For example, its useful to remember
> > that Kenny McCormack is a deliberately incoherent cartoon character,
> > aimed at adolescents and easily-amused adults.
>
> A lot of the versions of the Flash Gordon comics/cartoons have not been
> that serious either.

The difference is you name yourself, while calling Kenny, who appears
to post under his own name, a cartoon character.
> --
> Flash Gordon

==============================================================================
TOPIC: Style guides for C and/or C++
http://groups.google.com/group/comp.lang.c/t/8ac1309e95a1004a?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jan 18 2010 9:21 pm
From: pete

Vicent Giner-Bosch wrote:
> I've been searching at this forum and at the Internet for style guides
> for C and/or C++, and I've found this one:
>
> http://www.psgd.org/paul/docs/cstyle/cstyle.htm
>
> Also, I've read some threads about C style matters. I think there is
> really a lot of stuff!
>
> I just would like to ask you for a quick answer to this question:
> which style guide or style rules do you recommend me to use when
> writing C code? It would be great if many of you would answer, so we
> all could have here a thread with a good summary about this subject.
>
> Thank you for the feed-back!! :-)

I like that one, Indian Hill.

--
pete

== 2 of 2 ==
Date: Mon, Jan 18 2010 11:35 pm
From: William Ahern

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> Vicent Giner-Bosch <vginer@gmail.com> writes:
> >which style guide or style rules do you recommend me to use when
> >writing C code? It would be great if many of you would answer, so we
> >all could have here a thread with a good summary about this subject.

> http://www.lysator.liu.se/c/pikestyle.html

The "simple rule" regarding include files isn't very practical, though I can
appreciate the logic and the sentiment. In practice there are too many
issues.

First, most engineers are extremely annoyed by this practice. It means they
actually have to read your code (or documentation, even!). That's too much
to expect of others, for better or worse.

Second, the rule is, frankly, too simple. Should I force people to
separately include <stddef.h> because my header uses size_t? <limits.h> for
LONG_MAX? Many engineers will as a matter of course include <stdio.h>,
<stdlib.h>, and other boilerplate in the first few lines of their source
file. The whole exercise is lost on them, anyhow. If things break they'll be
completely baffled one way or the other.

Third, there are better ways to avoid the real evils. If my code needs to
use some huge library with a gazillion namespace polluting macros and
declarations, rather than expose this dependency in my header, I should use
encapsulation such that there's no source-level dependency to bother other
engineers. Even better, reduce dependencies altogether. It annoys me when
some library depends on glib just to re-use some simple data structure.
Forcing me to deal with those headers adds insult to injury. Pike's
/usr/include/sys example is atypical for a multitude of reasons.

The include guard hack is lamentable, but stems from fundamental quirks and
simplicities in the language design. It shouldn't be avoided merely because
the hack itself is ugly.

==============================================================================
TOPIC: Aborting
http://groups.google.com/group/comp.lang.c/t/ee63c59395130481?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 18 2010 9:33 pm
From: frank

Lew Pitcher wrote:
> On January 18, 2010 15:27, in comp.lang.c, ram@zedat.fu-berlin.de wrote:
>
>> Assuming that a program is in such a desperate situation,
>> that one wants to abort immediatly (for example, no more
>> memory is available), when should one use
>>
>> exit( 99 )
>>
>> (where »99« is a placeholder for any possible error code) and when
>>
>> abort()
>
> I would suspect that the decision to use abort() or exit() would depend a
> lot on the circumstances of the error, the goals of the application, and
> the QoI of the C implementation.
>
> abort()
> - does not guarantee to flush open buffered output streams,
> - does not guarantee to close open streams of any sort,
> - does not guarantee to remove temporary files, and
> - returns an implementation-defined "unsuccessful termination" status.

Is this last one synonymous with the requirement that __FILE__ and
__LINE__ be given?
>
> OTOH, exit()
> - executes the functions registered through the atexit() function
> - flushes open buffered output streams
> - closes all open streams
> - removes temporary files, and
> - returns a program-specified exit status to the host environment
>
> I'd use abort() only in the direst of circumstances, where the program logic
> cannot guarantee the sanity of /any/ of it's data. For all other
> terminations, I'd use exit().
>
> And, I'd document the use carefully, including expected behaviour and
> recovery options.

An interesting contrast, Lew. Which temporary files do you mean?
--
frank

==============================================================================
TOPIC: stack smashing
http://groups.google.com/group/comp.lang.c/t/0de180646e819463?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Jan 18 2010 9:48 pm
From: frank

Keith Thompson wrote:
> Michael Foukarakis <electricdelta@gmail.com> writes:
>> On Jan 17, 12:53 am, Richard Heathfield <r...@see.sig.invalid> wrote:
>>>> 2) Why do I not get 96.03 as the wiki promises?
>>> C does not define the behaviour of a program whose behaviour is
>>> undefined. So any result is okay, including the Wiki's result and any
>>> other result (or no result at all).
>> Puh-lease. :-) If only that were true, then exploits would fail half
>> the time, only because stack smashing invokes UB. Heh.
>
> Ah, but it is true. Any result is okay in the sense that it's
> permitted by the standard. That includes getting consistent results
> on a particular system, which is what exploits generally take
> advantage of.

It took me a while in this thread to figure out a) what stack-smashing
is and b) why my program was doing it.

When I worked up the example from the wiki in the original post, with
the 10.5 and the 96.1, one thing notable was that it didn't change that
value on my (ubuntu) implementation. It didn't succeed in changing that
value irrespective of how many characters I used in the buffer that was
being overrun. The OS detected it and refused to write to the stack
data inappropriately.

Also in researching this, I found out some sentinel values used by
stacks to prevent this type of hack. My friend mentioned 0x deadbeef as
one such value.
--
frank

== 2 of 3 ==
Date: Mon, Jan 18 2010 10:53 pm
From: jaysome

On Sun, 17 Jan 2010 09:54:55 +0000 (UTC), Antoninus Twink
<nospam@nospam.invalid> wrote:

>On 16 Jan 2010 at 22:53, Richard Heathfield wrote:
>> frank wrote:
>>> printf("a is %d\n", a);
>>
>> size_t is an unsigned integral type. If you want to pass a size_t to
>> printf to match a %d format specifier, cast it to int.
>
>This is exceptionally poor advice - and as usual, the famous "clc peer
>review" that would have seen half a dozen people piling in to point out
>that the resulting int might have been a trap representation or some
>such nonsense if a newbie had posted this remains strangely silent when
>it is one of their chums who's boobooed.

I disagree that it's "exceptionally poor advice", and would go further
to argue that it's sane advice, in most cases.

The C standard guarantees that INT_MAX is at least 32767, and the size
of any scalar type will always be less than this (at least in the real
world). Rather than casting the result of sizeof to "unsigned long",
it's simply easier to cast it to "int". In the instant case, we know
that the result of "sizeof(float)" is guaranteed to fit within type
int (again, in the real world).

In all of my years of development, I've never run into a case where
casting the return value of sizeof to "int" in a printf statement has
ever been a problem. If there were cases in which sizeof returned a
value greater than 32767, I was working on a platform in which the
compiler used 32-bit int, so it was not a problem. And if I had ever
ran into a case in which sizeof returned a value greater than 32767
and I was working on a platform in which the compiler used 16-bit int
(e.g., on some embedded devices), then, admittedly, I had bigger fish
to fry (like I don't even have 16K let alone 4K of RAM and thus the
printf code was never executed).

I find printf very useful in test programs to print out the size of my
user-defined (e.g., structure) types, and the pattern I use is:

printf("sizeof(T) is %d\n", (int)sizeof(T));

where T is my user-defined type.

--
jay

== 3 of 3 ==
Date: Mon, Jan 18 2010 11:01 pm
From: Michael Foukarakis

On Jan 18, 7:15 pm, Keith Thompson <ks...@mib.org> wrote:
> Michael Foukarakis <electricde...@gmail.com> writes:
> > On Jan 17, 12:53 am, Richard Heathfield <r...@see.sig.invalid> wrote:
> >> > 2)  Why do I not get 96.03 as the wiki promises?
>
> >> C does not define the behaviour of a program whose behaviour is
> >> undefined. So any result is okay, including the Wiki's result and any
> >> other result (or no result at all).
>
> > Puh-lease. :-) If only that were true, then exploits would fail half
> > the time, only because stack smashing invokes UB. Heh.
>
> Ah, but it is true.  Any result is okay in the sense that it's
> permitted by the standard.  That includes getting consistent results
> on a particular system, which is what exploits generally take
> advantage of.

Exactly - stack smashing is only related to the C standard until we
overrun a buffer; after that, there's a whole other system of rules to
break - not as meticulously defined or standardized as C (or any
programming language) but it's what makes it fun to break. :)

==============================================================================
TOPIC: A seg fault
http://groups.google.com/group/comp.lang.c/t/29205dee12daebeb?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jan 18 2010 11:15 pm
From: jaysome

On Sun, 17 Jan 2010 18:56:08 -0700, "BGB / cr88192"
<cr88192@hotmail.com> wrote:

[SNIP]

>8MB stack is for Linux, but not for Windows, which uses 4MB...

Note that the term "stack" is not even mentioned in the C Standard.

On platforms that use a "stack", its size typically depends on the
compiler, not the OS. For example, the Visual C++ compiler for Windows
uses a default stack size of 1 MB. It's been that way since at least
Visual V++ 6.0 and as far as I know even up to and including the
latest version. See this link:

http://msdn.microsoft.com/en-us/library/tdkhxaks(VS.71).aspx

When I run the OP's program under Windows compiled with Visual C++ 6.0
SP5, I get a "0xC00000FD: Stack Overflow" exception, because the stack
size exceeds 1 MB. If I add the "/stack:0x989680" linker option, the
program executes without an exception.

--
jay

== 2 of 2 ==
Date: Mon, Jan 18 2010 11:33 pm
From: Seebs

On 2010-01-19, jaysome <jaysome@spamcop.net> wrote:
> Note that the term "stack" is not even mentioned in the C Standard.

Yes. And for good reason...

> On platforms that use a "stack", its size typically depends on the
> compiler, not the OS. For example, the Visual C++ compiler for Windows
> uses a default stack size of 1 MB. It's been that way since at least
> Visual V++ 6.0 and as far as I know even up to and including the
> latest version. See this link:

See, here you surprise me. Of the two systems where I know off the top
of my head how stack space is allocated, in both cases, the limit is defined
by the OS, not by the compiler. (UNIX and AmigaDOS)

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

==============================================================================
TOPIC: Shorten this popcount and tesbed
http://groups.google.com/group/comp.lang.c/t/44cf66dcae62c3f5?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jan 18 2010 11:17 pm
From: Francois Grieu

sfuerst wrote :
> On Jan 18, 2:52 am, Francois Grieu <fgr...@gmail.com> wrote:
>> sfuerst wrote :
>>
>>> On Jan 17, 10:41 pm, Francois Grieu <fgr...@gmail.com> wrote:
>>>> sfuerst wrote :
>>>>> How about:
>>>>> #define P(n)(((n)&73)%7+((n)/2&73)%7+((n)/4&9)%7)
>>>> dense
>>> And this is even shorter:
>>> #define P(n)(((n)*0x8040201UL&~0/15UL)%15)
>>> Steven
>> Close, but at runtime, C89 allows ~0 to be two to the power n
>> minus one for any integer n at least 16; n is 16 on several of
>> my target platforms.
>> And even though n is 32 where I compile now, P(32) gives 0.
>>
>> Francois Grieu [reposted with correction]
>
> Yeah, the above only works with 64bit longs. Hopefully the following
> will work better on 32bit machines:
>
> #define P(n)(((n)*134480385u/8&~0ul/15)%15)

~0ul/15 assumes that unsigned long is n*4 bits. Also, an
unsigned int of 29 bits is OK by chapter and verse.

On the other hand, there is
#define P(n)(((n)*134480385UL/8&286331153)%15))
but it breaks no character size record. And I remember some
preprocessor that did not understand UL.

Francois Grieu

== 2 of 2 ==
Date: Mon, Jan 18 2010 11:59 pm
From: sfuerst

<snip>

> > Yeah, the above only works with 64bit longs.  Hopefully the following
> > will work better on 32bit machines:
>
> > #define P(n)(((n)*134480385u/8&~0ul/15)%15)
>
> ~0ul/15 assumes that unsigned long is n*4 bits. Also, an
> unsigned int of 29 bits is OK by chapter and verse.
>
> On the other hand, there is
> #define P(n)(((n)*134480385UL/8&286331153)%15))
> but it breaks no character size record. And I remember some
> preprocessor that did not understand UL.
>
>    Francois Grieu

To be ansi C, ULONG_MAX must be at least 4294967295, and thus have
enough dynamic range for ~0ul/15 to work for its intended purpose. :-)

You are right though, a perverse implementation with unsigned ints 29
bits long will cause the above to fail. In which case, you need to
spend an extra character to convert 134480385u into 134480385ul.
However, realistically speaking no such implementation exists, so I
wouldn't bother for real-world code. (Even machines with 9bit chars
end up with unsigned ints of 18bits, which will nicely promote to
36bit unsigned longs.)

Also, if the preprocessor doesn't understand the "ul" suffix, then you
aren't talking about C, but some other language. Remember, that an
undefined non-C compiler could do absolutely anything with valid C
code, so there isn't much point discussing hypotheticals unless you
have a particular implementation in mind. If so, discussing its
limitations, and the work-arounds required could be interesting, but
perhaps would be off-topic for this newsgroup.

Steven

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

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