What is wrong with this c-program?

[Albert van der Horst]

I have the following program that gives consistently a segfault
with
--------------------
46344 1
46345 1
46346 1
46347 1
46348 1
46349 0
Segmentation fault
-------------------

The program itself doesn't give any complaints with gcc 4.4
on a stable Debian.
It is a classical prime sieve.
I can't find any fault with it.

--------------------------

#include <stdio.h>
#include <assert.h>
#include <inttypes.h>

#define BYTE uint8_t

/* largest number */
#define MAXSIZE 20000000
#define SIZE 2000000

long int TheLimit;

/*****************************************************************************/
/* */
/* Fill the `nprimes' table up to `n' */
/* */
/*****************************************************************************/


static BYTE composite[ MAXSIZE+1];

void fill_primes( int n)
{
int i,j;

assert(n<=MAXSIZE);
for (i=0;i<=n; i++) composite[i] = 0;
for ( i=2; i<=n; i++)
{
printf("%d %d \n",i,composite[i]);
if (!composite[i])
{
for (j=i*i; j<=n; j+=i) composite[j] = 1;
}
}
}

int main( int argv, char** argc)
{
int i;
TheLimit = atoi(argc[1]);
printf("n= %d\n",TheLimit);
fill_primes(TheLimit);
printf("primes ready\n");
}

------------------------------


Must I suspect the installation of my compiler?

Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[D. Aaron Sawyer]

1. you fail to handle the case of a missing argument.
2. what is the size of int j? what is the maximum value an int can hold?
3. what is the value of 46349*46349 ?
4. compare the answer to 3 with that of 2b.
5. your compiler is fine. your code needs repair.

[Øyvind Røtvold]

Get yourself a debugger:

gdb)$ run 60000
......
46348 1
46349 0

Program received signal SIGSEGV, Segmentation fault.
0x080485f0 in fill_primes (n=60000) at nprim.c:34
34 for (j=i*i; j<=n; j+=i) composite[j] = 1;
(gdb)$ print j
$1 = -2146737495
(gdb)$


You will probably find that 46349*46349 > 2^31.


--
.. �yvind - soon to appear in a kill file near you.
.. Ignorance can be cured; stupidity is forever.

[Luuk]

46349 * 46349 = -2146737495

> }
> }
> }
>
> int main( int argv, char** argc)
> {
> int i;
> TheLimit = atoi(argc[1]);
> printf("n= %d\n",TheLimit);
> fill_primes(TheLimit);
> printf("primes ready\n");
> }
>
> ------------------------------
>
>
> Must I suspect the installation of my compiler?
>

you have an overflow,

[Ralph Spitzner]

�yvind R�tvold wrote:
[...]

> You will probably find that 46349*46349 > 2^31.

Perfect answer, kudos ! :-)


--
Mostly harmless...
-Douglas Adams

[Martin Ambuhl]

On 12/25/2013 8:09 AM, Albert van der Horst wrote:

> The program itself doesn't give any complaints with gcc 4.4
> on a stable Debian.
> It is a classical prime sieve.
> I can't find any fault with it.

At least the following is wrong:
1. You did not #include <stdlib.h>, needed for atoi (which is a poor
choice, any way)
2. You are trying to printf a long int with a %d specifier
3. You have failed to ask your compiler for an appropriate level of
warnings.

(2) probably explains your seg fault; (3) explains why gcc didn't complain.

> Must I suspect the installation of my compiler?

Why is it that novice programmers always want to blame their compiler
for their own errors?

[Geoff]

On 25 Dec 2013 13:09:30 GMT, alb...@spenarnc.xs4all.nl (Albert van der

Horst) wrote:

>I have the following program that gives consistently a segfault
>with
>--------------------
>46344 1
>46345 1
>46346 1
>46347 1
>46348 1
>46349 0
>Segmentation fault
>-------------------
>
>The program itself doesn't give any complaints with gcc 4.4
>on a stable Debian.
>It is a classical prime sieve.
>I can't find any fault with it.

You're not looking very hard. See below.

>
>--------------------------
>
>#include <stdio.h>
>#include <assert.h>
>#include <inttypes.h>

-----------^^^^^^^^^^
Non-standard header used.
You didn't include <limits.h>, <stdlib.h>.

>
>#define BYTE uint8_t

Why do this? Why not just use standard type unsigned char?

>
>/* largest number */
>#define MAXSIZE 20000000

Use INT_MAX from <limits.h> instead and use it directly in your assert
line below but even then the assert will fail to protect you.

>#define SIZE 2000000
This is never referenced again, delete it.

>
>long int TheLimit;
>
>/*****************************************************************************/
>/* */
>/* Fill the `nprimes' table up to `n' */
>/* */
>/*****************************************************************************/
>
>
>static BYTE composite[ MAXSIZE+1];
>
>void fill_primes( int n)
>{

> int i;
unsigned long long j;

>
> assert(n<=MAXSIZE);
> for (i=0;i<=n; i++) composite[i] = 0;
> for ( i=2; i<=n; i++)
> {
> printf("%d %d \n",i,composite[i]);
> if (!composite[i])
> {
> for (j=i*i; j<=n; j+=i) composite[j] = 1;
> }
> }
>}
>
>int main( int argv, char** argc)
>{
> int i;

Unused variable i.

> TheLimit = atoi(argc[1]);
> printf("n= %d\n",TheLimit);
> fill_primes(TheLimit);
> printf("primes ready\n");
>}
>
>------------------------------
>
>
>Must I suspect the installation of my compiler?
>

No, your compiler is fine, your usage of it is flawed.

Use the -Wall switch and your compiler will talk to you.

[Noob]

Geoff wrote:

> Albert van der Horst wrote:
>

>> #include <inttypes.h>
> -----------^^^^^^^^^^
> Non-standard header used.

inttypes.h /is/ a standard C99 header.
https://en.wikibooks.org/wiki/C_Programming/C_Reference/inttypes.h

>> #define BYTE uint8_t
>
> Why do this? Why not just use standard type unsigned char?

@Geoff: unsigned char /may/ be wider than 8 bits.

@Albert: a typedef seems more appropriate than a macro.
typedef uint8_t byte;

>> /* largest number */
>> #define MAXSIZE 20000000
>
> Use INT_MAX from <limits.h> instead

Allocating INT_MAX+1 ints is unlikely to succeed (except on Win64)

> Use the -Wall switch and your compiler will talk to you.

Some people also add -Wextra -O2 to enable even more warnings.

[Keith Thompson]

Noob <root@localhost> writes:
> Geoff wrote:
>> Albert van der Horst wrote:

[...]

>>> #define BYTE uint8_t
>>
>> Why do this? Why not just use standard type unsigned char?
>
> @Geoff: unsigned char /may/ be wider than 8 bits.

And if it is, then uint8_t will not exist. (Which means the program
will fail to compile; if it depends on 8-bit bytes, that's probably a
good thing.)

[...]

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Dr Nick]

Others have pointed out lots of errors. Here's one of the biggest and
one no compiler can protect you against: a stonking great comment that
doesn't actually tell you much and - crucially - what it tells you is
wrong: there is no nprimes table.

> static BYTE composite[ MAXSIZE+1];
>
> void fill_primes( int n)

I find calling a function "fill_primes" when what it does is to fill a
table called "composite" a little confusing.

> {
> int i,j;
>
> assert(n<=MAXSIZE);
> for (i=0;i<=n; i++) composite[i] = 0;
> for ( i=2; i<=n; i++)
> {
> printf("%d %d \n",i,composite[i]);
> if (!composite[i])
> {
> for (j=i*i; j<=n; j+=i) composite[j] = 1;
> }
> }
> }
>
> int main( int argv, char** argc)
> {
> int i;
> TheLimit = atoi(argc[1]);
> printf("n= %d\n",TheLimit);
> fill_primes(TheLimit);
> printf("primes ready\n");
> }
>
> ------------------------------
>
>
> Must I suspect the installation of my compiler?

No.

[BartC]

"Geoff" <ge...@invalid.invalid> wrote in message
news:d4gnb9lumta61nscc...@4ax.com...

> On 25 Dec 2013 13:09:30 GMT, alb...@spenarnc.xs4all.nl (Albert van der
> Horst) wrote:

>>#define BYTE uint8_t
>
> Why do this? Why not just use standard type unsigned char?

Because 'byte' (as I would write it) is a lot shorter (and easier on the eye
than 'uint8_t'). And it explains more, because everyone knows what a byte
is. Also that a byte* type probably isn't going to used for strings.

--
Bartc

[Martin Ambuhl]

On 12/26/2013 5:46 AM, BartC wrote:
>> On 25 Dec 2013 13:09:30 GMT, alb...@spenarnc.xs4all.nl (Albert van der
>> Horst) wrote:

>>> #define BYTE uint8_t

> Because 'byte' (as I would write it) is a lot shorter (and easier on the
> eye than 'uint8_t'). And it explains more, because everyone knows what a
> byte is. Also that a byte* type probably isn't going to used for strings.

This is wrong. It is _not_ true that "everyone knows what a byte is".
In fact, it seems that _you_ do not know what a byte is.

[Kenny McCormack]

In article <ePKdnaTOa4FovSHP...@earthlink.com>,

Boys, boys, boys!

You guys really need to get a room!

--
Here's a simple test for Fox viewers:

1) Sit back, close your eyes, and think (Yes, I know that's hard for you).
2) Think about and imagine all of your ridiculous fantasies about Barack Obama.
3) Now, imagine that he is white. Cogitate on how absurd your fantasies
seem now.

See? That wasn't hard, was it?

[Noob]

BartC wrote:

> 'byte' [...] is a lot shorter (and easier on the eye) than 'uint8_t'.

> And it explains more, because everyone knows what a byte is.

No. Use "octet" if you need a word for uint8_t, not "byte".

"byte" is a pun on "bit/bite". It conveys no size information.

> Also that a byte* type probably isn't going to used for strings.

I don't think anyone would use (unsigned char *) for strings either.

[Seebs]

On 2013-12-26, BartC <b...@freeuk.com> wrote:
> "Geoff" <ge...@invalid.invalid> wrote in message
> news:d4gnb9lumta61nscc...@4ax.com...
>> On 25 Dec 2013 13:09:30 GMT, alb...@spenarnc.xs4all.nl (Albert van der
>> Horst) wrote:

>>>#define BYTE uint8_t

>> Why do this? Why not just use standard type unsigned char?

> Because 'byte' (as I would write it) is a lot shorter (and easier on the eye
> than 'uint8_t').

It might be easier on the eye, but it's also unfamiliar.

> And it explains more, because everyone knows what a byte is.

C programmers had better know what an unsigned char is. Furthermore,
"byte" has a lot of implications which appear to be possibly-false and
definitely-irrelevant to your program.

> Also that a byte* type probably isn't going to used for strings.

But that's misleading, because of course it could be.

-s
--
Copyright 2013, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
Autism Speaks does not speak for me. http://autisticadvocacy.org/
I am not speaking for my employer, although they do rent some of my opinions.

[BartC]

"Noob" <root@localhost> wrote in message
news:52bc282e$0$2945$426a...@news.free.fr...

> BartC wrote:
>
>> 'byte' [...] is a lot shorter (and easier on the eye) than 'uint8_t'.
>> And it explains more, because everyone knows what a byte is.
>
> No. Use "octet" if you need a word for uint8_t, not "byte".

> "byte" is a pun on "bit/bite". It conveys no size information.

No? If you had to make an educated guess as to the number of bits in a
'byte' type, and your life depending on it, what would be your best guess;
11?

I always liked to think, myself, that a bit was an eight of a byte, in the
same way that a bit is an eighth of a dollar.

But apart from my opinion, the Wikipedia article suggests that an 8-bit byte
is the 'de factor standard'; that it has ubiquitous acceptance (other than
in c.l.c obviously); and that that meaning is ratified by a formal
international standard.

While 'octet' is used where unambiguity is needed (ignoring by the ambiguity
caused by people who've never heard of an octet).

Anyway, if the width of a 'byte' type alias in C source code is ambiguous,
then so is the width of a 'char' type.

>> Also that a byte* type probably isn't going to used for strings.
>
> I don't think anyone would use (unsigned char *) for strings either.

I use a macro 'uchar', with strings being uchar*, since I don't want any
nasty surprises from the possible signedness of a char type.

--
Bartc

[Bill Leary]

"BartC" wrote in message news:fOTuu.983$v04...@fx28.am4...

If you really mean 8 bits, "octet" is the better choice. Granted that
"byte" most commonly means 8 bits, but (revealing my age here) I've also
seen "byte" represent data entities of 5, 6, 7 and 9 bits on various
machines.

- Bill

[Richard]

No. Everyone doesnt know what a byte it.


--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

[Richard]

As nice as ever. God forbid a bighead like you should venture a clean
decisive meaning in this hotbed of antiquated egos.

[Richard]

Seebs <usenet...@seebs.net> writes:

> On 2013-12-26, BartC <b...@freeuk.com> wrote:
>> "Geoff" <ge...@invalid.invalid> wrote in message
>> news:d4gnb9lumta61nscc...@4ax.com...
>>> On 25 Dec 2013 13:09:30 GMT, alb...@spenarnc.xs4all.nl (Albert van der
>>> Horst) wrote:
>
>>>>#define BYTE uint8_t
>
>>> Why do this? Why not just use standard type unsigned char?
>
>> Because 'byte' (as I would write it) is a lot shorter (and easier on the eye
>> than 'uint8_t').
>
> It might be easier on the eye, but it's also unfamiliar.
>
>> And it explains more, because everyone knows what a byte is.
>
> C programmers had better know what an unsigned char is. Furthermore,
> "byte" has a lot of implications which appear to be possibly-false and
> definitely-irrelevant to your program.
>
>> Also that a byte* type probably isn't going to used for strings.
>
> But that's misleading, because of course it could be.
>
> -s

Yes, only the other day we were told a char * doesnt point to a string
*boggle*. Only in c.l.c has language been so distorted by petty,
posturing ninnies.

[Richard]

Noob <root@localhost> writes:

> BartC wrote:
>
>> 'byte' [...] is a lot shorter (and easier on the eye) than 'uint8_t'.
>> And it explains more, because everyone knows what a byte is.
>
> No. Use "octet" if you need a word for uint8_t, not "byte".
>
> "byte" is a pun on "bit/bite". It conveys no size information.

Except in the real world of course where pretty much everyone uses it to
refer to 8 bits. But yes, you're right...

>
>> Also that a byte* type probably isn't going to used for strings.
>
> I don't think anyone would use (unsigned char *) for strings either.
>

[Richard]

"BartC" <b...@freeuk.com> writes:

> "Noob" <root@localhost> wrote in message
> news:52bc282e$0$2945$426a...@news.free.fr...
>> BartC wrote:
>>
>>> 'byte' [...] is a lot shorter (and easier on the eye) than 'uint8_t'.
>>> And it explains more, because everyone knows what a byte is.
>>
>> No. Use "octet" if you need a word for uint8_t, not "byte".
>
>> "byte" is a pun on "bit/bite". It conveys no size information.
>
> No? If you had to make an educated guess as to the number of bits in a
> 'byte' type, and your life depending on it, what would be your best guess;
> 11?
>
> I always liked to think, myself, that a bit was an eight of a byte, in the
> same way that a bit is an eighth of a dollar.
>
> But apart from my opinion, the Wikipedia article suggests that an 8-bit byte
> is the 'de factor standard'; that it has ubiquitous acceptance (other than
> in c.l.c obviously); and that that meaning is ratified by a formal
> international standard.
>

It is. Don't worry yourself. The c.l.c overlords just love a chance to out
net nanny the other. You gave them all their Christmas presents at once.

[Keith Thompson]

"BartC" <b...@freeuk.com> writes:
> "Noob" <root@localhost> wrote in message
> news:52bc282e$0$2945$426a...@news.free.fr...
>> BartC wrote:

[...]

>>> Also that a byte* type probably isn't going to used for strings.
>>
>> I don't think anyone would use (unsigned char *) for strings either.
>
> I use a macro 'uchar', with strings being uchar*, since I don't want any
> nasty surprises from the possible signedness of a char type.

Why is "uchar" a macro rather than a typedef?

And what's the advantage of "uchar" over "unsigned char"? If I see
"unsigned char" in your code, I know exactly what it means; if I see
"uchar", I'm only about 98% sure.

[James Kuyper]

On 12/25/2013 11:46 PM, Martin Ambuhl wrote:
...

> Why is it that novice programmers always want to blame their compiler
> for their own errors?

They know, from a user perspective, that defective software is
commonplace, so they suspect the compiler. They have not yet learned
that the reason why defective software is commonplace is that it's very
hard to write defect-free code, so they underestimate the likelihood
that it's a mistake in their own code.

[BartC]

"Keith Thompson" <ks...@mib.org> wrote in message
news:lneh4za...@nuthaus.mib.org...

> "BartC" <b...@freeuk.com> writes:

>> I use a macro 'uchar', with strings being uchar*, since I don't want any
>> nasty surprises from the possible signedness of a char type.
>
> Why is "uchar" a macro rather than a typedef?

<shrug> It just is. It saves the slight pause that happens with typedef
where I try and remember which way around things are supposed to be.

> And what's the advantage of "uchar" over "unsigned char"? If I see
> "unsigned char" in your code, I know exactly what it means; if I see
> "uchar", I'm only about 98% sure.

98% is good enough. It helps stop the code from sprawling and saves typing.
I'm sure you also appreciate C choosing 'int' and 'char' rather than
'integer' and 'character'.

--
Bartc

[Keith Thompson]

"BartC" <b...@freeuk.com> writes:
> "Keith Thompson" <ks...@mib.org> wrote in message
> news:lneh4za...@nuthaus.mib.org...
>> "BartC" <b...@freeuk.com> writes:
>>> I use a macro 'uchar', with strings being uchar*, since I don't want any
>>> nasty surprises from the possible signedness of a char type.
>>
>> Why is "uchar" a macro rather than a typedef?
>
> <shrug> It just is. It saves the slight pause that happens with typedef
> where I try and remember which way around things are supposed to be.

Ok. Not the way I'd do it, though. And a bit of practice should
alleviate the problem of remembering how typedefs are defined.

>> And what's the advantage of "uchar" over "unsigned char"? If I see
>> "unsigned char" in your code, I know exactly what it means; if I see
>> "uchar", I'm only about 98% sure.
>
> 98% is good enough. It helps stop the code from sprawling and saves typing.
> I'm sure you also appreciate C choosing 'int' and 'char' rather than
> 'integer' and 'character'.

Not particularly, no. I've used languages that spell out their type
names, and I've never has any particular problem with it.

On the other hand, in C "integer" and "character" are more generic terms
(there are several integer types, of which "int" is just one; likewise
for character types). That might be considered a rationale for using
the shorter names, though I don't believe that was the original reason.

98% tends not to be good enough *for me* when I can get 100% at the
trivial cost of a little extra typing. YMMV.

[Geoff]

On Thu, 26 Dec 2013 07:22:54 +0100, Noob <root@localhost> wrote:

>Geoff wrote:
>
>> Albert van der Horst wrote:
>>
>>> #include <inttypes.h>
>> -----------^^^^^^^^^^
>> Non-standard header used.
>
>inttypes.h /is/ a standard C99 header.
>https://en.wikibooks.org/wiki/C_Programming/C_Reference/inttypes.h
>

I stand corrected. I looked it up in N1570 and saw I was mistaken only
after I had sent the post. I blame the eggnog. :)

>>> #define BYTE uint8_t
>>
>> Why do this? Why not just use standard type unsigned char?
>
>@Geoff: unsigned char /may/ be wider than 8 bits.
>

A good time to use the #error directive then, isn't it?

>@Albert: a typedef seems more appropriate than a macro.
>typedef uint8_t byte;
>
>>> /* largest number */
>>> #define MAXSIZE 20000000
>>
>> Use INT_MAX from <limits.h> instead
>

More eggnog abuse. Upon review he's not using that value as I
initially perceived him to be using it.

>Allocating INT_MAX+1 ints is unlikely to succeed (except on Win64)
>
>> Use the -Wall switch and your compiler will talk to you.
>
>Some people also add -Wextra -O2 to enable even more warnings.

Agreed.

[Geoff]

Upon further review, I were rewriting his code I'd bypass the byte vs.
BYTE vs. char issue altogether and use bool for the type of
composite[] because that's what he's using it as. It has only two
values and he could write it much more clearly using true and false.

[Geoff]

A lovely post and exactly right. I'll bet you smoke a pipe, don't you
doctor?

[Seebs]

On 2013-12-26, BartC <b...@freeuk.com> wrote:

> "Noob" <root@localhost> wrote in message
> news:52bc282e$0$2945$426a...@news.free.fr...

>> "byte" is a pun on "bit/bite". It conveys no size information.

> No? If you had to make an educated guess as to the number of bits in a
> 'byte' type, and your life depending on it, what would be your best guess;
> 11?

My best *guess* would be 8, but I would hate to rely on that, because
it's sometimes wrong.

> Anyway, if the width of a 'byte' type alias in C source code is ambiguous,
> then so is the width of a 'char' type.

Sure. But at least I know for sure what a char *is*. I can't be as confident
that I know what someone meant when they called something a "byte".

[Robert Wessel]

I'm not sure that's necessarily it. Weinberg ("The Psychology of
Computer Programming") describes the same attitude, even amongst some
supposedly "professional" (and experienced) programmers, way back in
the 60s. To the point where some people would routinely submit
failing jobs a second time (*without* inspection), on the assumption
that the machine/OS/compiler/operators/whatever were more likely to be
the reason for the failure than themselves.

Of course if you hang around this profession long enough, you will
find compiler bugs, but they are very rare. They do tend to be
memorable though, as finding them is often a quite difficult and
lengthy process.

[Bill Leary]

"Robert Wessel" wrote in message
news:aq5qb91iv5c47enek...@4ax.com...

> Of course if you hang around this profession long enough,
> you will find compiler bugs, but they are very rare. They do
> tend to be memorable though, as finding them is often a
> quite difficult and lengthy process.

I've been at this since the late 70's. I've encountered bugs in C compilers
four times. Three with the same compiler. And, once, in the "lseek"
function that came with another compiler package. Yes, it took a long time
to debug. And yes, they're memorable.

- Bill

[Keith Thompson]

"BartC" <b...@freeuk.com> writes:
> "Noob" <root@localhost> wrote in message
> news:52bc282e$0$2945$426a...@news.free.fr...
>> BartC wrote:
>>
>>> 'byte' [...] is a lot shorter (and easier on the eye) than 'uint8_t'.
>>> And it explains more, because everyone knows what a byte is.
>>
>> No. Use "octet" if you need a word for uint8_t, not "byte".
>
>> "byte" is a pun on "bit/bite". It conveys no size information.
>
> No? If you had to make an educated guess as to the number of bits in a
> 'byte' type, and your life depending on it, what would be your best guess;
> 11?

No, CHAR_BIT.

[...]

[Jorgen Grahn]

On Fri, 2013-12-27, Robert Wessel wrote:
> On Thu, 26 Dec 2013 11:53:33 -0500, James Kuyper
> <james...@verizon.net> wrote:
>
>>On 12/25/2013 11:46 PM, Martin Ambuhl wrote:
>>...
>>> Why is it that novice programmers always want to blame their compiler
>>> for their own errors?
>>
>>They know, from a user perspective, that defective software is
>>commonplace, so they suspect the compiler. They have not yet learned
>>that the reason why defective software is commonplace is that it's very
>>hard to write defect-free code, so they underestimate the likelihood
>>that it's a mistake in their own code.
>
> I'm not sure that's necessarily it. Weinberg ("The Psychology of
> Computer Programming") describes the same attitude, even amongst some
> supposedly "professional" (and experienced) programmers, way back in
> the 60s.

My practical experience, too, today. Although the /very/ experienced
can see that it's unlikely that a widely used version of gcc, for a
popular target and with commonly used flags has spectacular bugs.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Jorgen Grahn]

On Thu, 2013-12-26, Richard wrote:
> Noob <root@localhost> writes:
>
>> BartC wrote:
>>
>>> 'byte' [...] is a lot shorter (and easier on the eye) than 'uint8_t'.
>>> And it explains more, because everyone knows what a byte is.
>>
>> No. Use "octet" if you need a word for uint8_t, not "byte".
>>
>> "byte" is a pun on "bit/bite". It conveys no size information.
>
> Except in the real world of course where pretty much everyone uses it to
> refer to 8 bits. But yes, you're right...

Pretty much everyone use machines where octet, byte, uint8_t and char
are the same thing modulo signedness. But when you're writing C code
you have to acknowledge that it may be compiled for a machine where
this isn't true ... or somehow make it clear that you don't intend to
support exotic architectures.

[Ian Collins]

Well uint8_t will be consistent (if present), so you may as well use it.

--
Ian Collins

[Jorgen Grahn]

On Wed, 2013-12-25, Albert van der Horst wrote:
> I have the following program that gives consistently a segfault
> with
> --------------------
> 46344 1
> 46345 1
> 46346 1
> 46347 1
> 46348 1
> 46349 0
> Segmentation fault
> -------------------
>
> The program itself doesn't give any complaints with gcc 4.4
> on a stable Debian.

I get four warnings when compiling it (also on Debian stable, good
choice by the way) and one hint from valgrind when it segfaults.
(Valgrind doesn't give more information than a core dump would have in
this case though.)

> It is a classical prime sieve.
> I can't find any fault with it.

Use the few troubleshooting tools which are available to you; it frees
up your brain for more important tasks.

> #include <stdio.h>
> #include <assert.h>
> #include <inttypes.h>
>
> #define BYTE uint8_t
>
> /* largest number */
> #define MAXSIZE 20000000
> #define SIZE 2000000
>
> long int TheLimit;
>
> /*****************************************************************************/
> /* */
> /* Fill the `nprimes' table up to `n' */
> /* */
> /*****************************************************************************/
>
>

> static BYTE composite[ MAXSIZE+1];
>
> void fill_primes( int n)

> {
> int i,j;
>
> assert(n<=MAXSIZE);
> for (i=0;i<=n; i++) composite[i] = 0;
> for ( i=2; i<=n; i++)
> {
> printf("%d %d \n",i,composite[i]);
> if (!composite[i])
> {
> for (j=i*i; j<=n; j+=i) composite[j] = 1;
> }
> }
> }
>
> int main( int argv, char** argc)

sun.c:38:15: warning: unused parameter 'argv'

You have reversed the meanings of argv and argc -- "v" is for "vector"
and "c" is for "count". Not a bug, but unusual and confusing!

> {
> int i;

sun.c:40:9: warning: unused variable 'i'

> TheLimit = atoi(argc[1]);

sun.c:41:5: warning: implicit declaration of function 'atoi'

> printf("n= %d\n",TheLimit);

sun.c:42:5: warning: format '%d' expects argument of type 'int', but
argument 2 has type 'long int'

> fill_primes(TheLimit);
> printf("primes ready\n");
> }

[Jorgen Grahn]

On Thu, 2013-12-26, Dr Nick wrote:
> alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:

...
>> /************************************************************************/

>> /* */
>> /* Fill the `nprimes' table up to `n' */
>> /* */

>> /************************************************************************/

>
> Others have pointed out lots of errors. Here's one of the biggest and
> one no compiler can protect you against: a stonking great comment that
> doesn't actually tell you much and - crucially - what it tells you is
> wrong: there is no nprimes table.

Two observations of mine:
- The fresher the novice, the more elaborate comment blocks.
- The more elaborate the comment block, the less useful its content.

[Richard]

Jorgen Grahn <grahn...@snipabacken.se> writes:

> On Thu, 2013-12-26, Richard wrote:
>> Noob <root@localhost> writes:
>>
>>> BartC wrote:
>>>
>>>> 'byte' [...] is a lot shorter (and easier on the eye) than 'uint8_t'.
>>>> And it explains more, because everyone knows what a byte is.
>>>
>>> No. Use "octet" if you need a word for uint8_t, not "byte".
>>>
>>> "byte" is a pun on "bit/bite". It conveys no size information.
>>
>> Except in the real world of course where pretty much everyone uses it to
>> refer to 8 bits. But yes, you're right...
>
> Pretty much everyone use machines where octet, byte, uint8_t and char
> are the same thing modulo signedness. But when you're writing C code
> you have to acknowledge that it may be compiled for a machine where

You don't have to do anything of the kind. It doesnt take a genius to
assume the general truth when nothing else indicates otherwise.

I do understand the reasoning - however one must keep it real. A Byte is
8 bits in 99.99% of places and meeting rooms. If we must be pedantic
each and every time then that might be fine for c.l.c but not for most
people - for others its tiresome pedantry designed to irritate.

> this isn't true ... or somehow make it clear that you don't intend to
> support exotic architectures.
>

Or, and better, make it clear when you do.

ie this code is designed to be multi platform and support multiple byte
sizes.etc etc

[David Brown]

On 27/12/13 00:05, Geoff wrote:
> On Thu, 26 Dec 2013 07:22:54 +0100, Noob <root@localhost> wrote:
>
>> Geoff wrote:
>>
>>> Albert van der Horst wrote:
>>>
>>>> #include <inttypes.h>
>>> -----------^^^^^^^^^^
>>> Non-standard header used.
>>
>> inttypes.h /is/ a standard C99 header.
>> https://en.wikibooks.org/wiki/C_Programming/C_Reference/inttypes.h
>>
> I stand corrected. I looked it up in N1570 and saw I was mistaken only
> after I had sent the post. I blame the eggnog. :)
>
>>>> #define BYTE uint8_t
>>>
>>> Why do this? Why not just use standard type unsigned char?
>>
>> @Geoff: unsigned char /may/ be wider than 8 bits.
>>
>
> A good time to use the #error directive then, isn't it?

Nah, why clutter up the program with extra lines and #error directives
for a situation that almost certainly will not occur? Just use
"uint8_t" and let the compiler give an error that is marginally harder
to understand if you have a platform without 8-bit support.

Alternatively, use uint_least8_t, which will exist.

>
>> @Albert: a typedef seems more appropriate than a macro.
>> typedef uint8_t byte;
>>

It seems to me that using "uint8_t" directly is more appropriate than a
macro /or/ a typedef. If you want to use a new type name here, then a
typedef to an appropriate name (such as "typedef uint8_t flag_t;") would
be more useful.

[David Brown]

On 27/12/13 05:08, Seebs wrote:
> On 2013-12-26, BartC <b...@freeuk.com> wrote:
>> "Noob" <root@localhost> wrote in message
>> news:52bc282e$0$2945$426a...@news.free.fr...
>>> "byte" is a pun on "bit/bite". It conveys no size information.
>
>> No? If you had to make an educated guess as to the number of bits in a
>> 'byte' type, and your life depending on it, what would be your best guess;
>> 11?
>
> My best *guess* would be 8, but I would hate to rely on that, because
> it's sometimes wrong.
>
>> Anyway, if the width of a 'byte' type alias in C source code is ambiguous,
>> then so is the width of a 'char' type.
>
> Sure. But at least I know for sure what a char *is*. I can't be as confident
> that I know what someone meant when they called something a "byte".
>

I have used processors with 16-bit "char", and no way to make an 8-bit
type (except as a bitfield). Nowhere, in any of the documentation,
manuals, datasheets, or anywhere else was there any reference to a
"byte" that is not 8 bits. It made clear that a /char/ was 16 bits
rather than the usual 8 bits, but they were never called "bytes".

I haven't used such devices much - but the vast majority of people who
use the term "byte" have never even heard of such devices, never mind
used them.

There are only two situations when "byte" does not automatically and
unequivocally mean "8 bits" - one is in reference to ancient computer
history (and documents from that era, such as network RFC's), and the
other is extreme pedantry. There is a time and place for both of these
- but you won't convince many people that you would ever /really/ think
a reference to a "byte" meant anything other than 8 bits.

(If you can give modern, or at least still-current, references to usage
of "byte" for something other than 8 bits, then I will recant and blame
the egg nog!.)

A "char", as you say, has a well defined meaning - but not a well
defined size.

[James Kuyper]

On 12/29/2013 09:14 AM, David Brown wrote:
...

> - but you won't convince many people that you would ever /really/ think
> a reference to a "byte" meant anything other than 8 bits.

Why should it be so hard to convince people of that? I can imagine
having a hard time convincing people that "byte" means anything other
than 8 bits (obviously, that only applies to people who don't consider
the C standard authoritative) - however, why should it be difficult to
convince other people that *I* believe it to be true?
--
James Kuyper

[osmium]

A byte that is not 8 bits is indeed rare, but I am certain there has been
such usage in a more or less valid way. The 9-bit chunk on a Univac 11000
series for example. I note you stuck "modern" in there as a qualifier. To
refer to that system as a Unisys whatever (to modernize it), just obfuscates
things. This thread has a lot more to do with pedants inheriting the earth
than anything else. Or at least co.law.co.

In a similar vein, anyone who spells that hard rive thingy as a disc instead
of a disk is late to the party as far as I am concerned.

[osmium]

"osmium" wrote:

> Or at least co.law.co.

c.l.c. Damn!

[Phil Carmody]

I've thought various things along those lines in the past, but your
rendering of the concept is absolutely perfect!

Were there a list of C koans, that should be part of it.

Phil
--
The list of trusted root authorities in your browser included the
United Arab Emirates-based Etisalat, which was caught secretly
uploading spyware onto 100,000 customers' BlackBerries.
http://www.wired.com/threatlevel/2009/07/blackberry-spies/

[Phil Carmody]

Kinda-piggybacking, OP not visible to me.

Jorgen Grahn <grahn...@snipabacken.se> writes:
> On Wed, 2013-12-25, Albert van der Horst wrote:
> > I have the following program that gives consistently a segfault
> > with
> > --------------------
> > 46344 1
> > 46345 1
> > 46346 1
> > 46347 1
> > 46348 1
> > 46349 0
> > Segmentation fault
> > -------------------
> >
> > The program itself doesn't give any complaints with gcc 4.4
> > on a stable Debian.
>
> I get four warnings when compiling it (also on Debian stable, good
> choice by the way) and one hint from valgrind when it segfaults.
> (Valgrind doesn't give more information than a core dump would have in
> this case though.)
>
> > It is a classical prime sieve.
> > I can't find any fault with it.
>
> Use the few troubleshooting tools which are available to you; it frees
> up your brain for more important tasks.

The brain might be the perfect tool for the job. A bug in the code jumped
out quicker than it would have taken me to copy/paste, compile, and run
under gdb.

> > #include <stdio.h>
> > #include <assert.h>
> > #include <inttypes.h>
> >
> > #define BYTE uint8_t
> >
> > /* largest number */
> > #define MAXSIZE 20000000
> > #define SIZE 2000000
> >
> > long int TheLimit;
> >
> > /*****************************************************************************/
> > /* */
> > /* Fill the `nprimes' table up to `n' */
> > /* */
> > /*****************************************************************************/
> >
> >
> > static BYTE composite[ MAXSIZE+1];
> >
> > void fill_primes( int n)
> > {
> > int i,j;
> >
> > assert(n<=MAXSIZE);
> > for (i=0;i<=n; i++) composite[i] = 0;
> > for ( i=2; i<=n; i++)
> > {
> > printf("%d %d \n",i,composite[i]);
> > if (!composite[i])
> > {
> > for (j=i*i;

BANG!!! i*i will be negative at some point.
A wild stab in the dark, some point around i=46349.

Possible solutions:
(1) Generally - Use unsigned integer types for things you know can never
be negative. (but take care to make sure those assumptions don't mess
things up, loops that count down can often cause newbs problems.)
(2) This particular case - Stop the sieving loop as soon as you're sure
that no more composites can be sieved out. So don't loop i up to n, loop
op to sqrt(n) instead, and then just dump the rest of the contents out
in a trivial loop without sieving.

[Bill Leary]

"osmium" wrote in message news:biatqo...@mid.individual.net...
> ((..much omitted..))

> In a similar vein, anyone who spells that hard rive thingy as a disc
> instead of a disk is late to the party as far as I am concerned.

Always a chuckle when someone commenting on spelling spells something wrong.
So I probably will somewhere in here too.

We'll assume "hard rive" means "hard drive."

The spelling of name for a flat circular object is regional. "Disk" is
generally American usage whereas "disc" seems to be common other places.
I've heard the same lament, the other way around, from Europeans I've worked
with. Some just thought we were being provincial, others considered our
spelling to be barbaric. Similar comments about "color" vs. "colour."

- Bill
________
"It’s a damn poor mind that can only think of one way to spell a word."
-- Andrew Jackson

[Paul]

Bill Leary wrote:
> "osmium" wrote in message news:biatqo...@mid.individual.net...
>> ((..much omitted..))
>> In a similar vein, anyone who spells that hard rive thingy as a disc
>> instead of a disk is late to the party as far as I am concerned.
>
> Always a chuckle when someone commenting on spelling spells something
> wrong. So I probably will somewhere in here too.
>
> We'll assume "hard rive" means "hard drive."
>
> The spelling of name for a flat circular object is regional. "Disk" is
> generally American usage whereas "disc" seems to be common other places.
> I've heard the same lament, the other way around, from Europeans I've
> worked with. Some just thought we were being provincial, others
> considered our spelling to be barbaric. Similar comments about "color"
> vs. "colour."
>
> - Bill

Disc is used for optical media.
Disk is used for hard drives.

http://en.wikipedia.org/wiki/Disc

Magnetic disk
http://en.wikipedia.org/wiki/Disk_drive
"The choice... is frequently historical,
as in... "IBM 350 disk storage unit"."

Optical disc (i.e. discus/frisbee)
http://en.wikipedia.org/wiki/Frisbee
http://en.wikipedia.org/wiki/Discus

Paul

[osmium]

"Bill Leary" wrote:

> "osmium" wrote in message news:biatqo...@mid.individual.net...
>> ((..much omitted..))
>> In a similar vein, anyone who spells that hard rive thingy as a disc
>> instead of a disk is late to the party as far as I am concerned.
>
> Always a chuckle when someone commenting on spelling spells something
> wrong. So I probably will somewhere in here too.
>
> We'll assume "hard rive" means "hard drive."
>
> The spelling of name for a flat circular object is regional. "Disk" is
> generally American usage whereas "disc" seems to be common other places.
> I've heard the same lament, the other way around, from Europeans I've
> worked with. Some just thought we were being provincial, others
> considered our spelling to be barbaric. Similar comments about "color"
> vs. "colour."

My mind set when I made my post. Disc is the proper US spelling for a disc,
say a Frisbee. But someone in IBM spelled it disk and it stuck so all
computer people should spell it disk. After all, IBM can do no wrong.

I just tried to verify what I thought I knew and the first response from
google for disc is disk! I don't think I have any paper dictionaries any
more but drilling down in google seems to verify my earlier thoughts. Google
was just "helping" me.

[David Brown]

It's a matter of believability. Certainly some people believe in things
that others find unlikely, which is fair enough. But if you were to say
"I believe the moon is made of cheese", I would not believe that you
believe that. Obviously sticking to old-fashioned definitions of a term
like "byte" isn't quite that extreme - but if you say, without reference
or additional qualification, that you believe a reference to a "byte" in
current writing might reasonably refer to something other than 8 bits,
then I would not take you literally. I would assume you are
exaggerating, joking, playing the devil's advocate, or otherwise trying
to make a point in some way, or perhaps you have misread the question or
mistyped the answer. (But I certainly won't assume you are lying or
"trolling".) If you repeat your belief, I'll accept it - but until I
was sure, I'd assume there was some other explanation.

But I think this is getting a bit too philosophical - I'm off to watch
Mr. Bean's New Year :-)

[Jorgen Grahn]

On Sun, 2013-12-29, Richard wrote:
> Jorgen Grahn <grahn...@snipabacken.se> writes:
>
>> On Thu, 2013-12-26, Richard wrote:
>>> Noob <root@localhost> writes:
>>>
>>>> BartC wrote:
>>>>
>>>>> 'byte' [...] is a lot shorter (and easier on the eye) than 'uint8_t'.
>>>>> And it explains more, because everyone knows what a byte is.
>>>>
>>>> No. Use "octet" if you need a word for uint8_t, not "byte".
>>>>
>>>> "byte" is a pun on "bit/bite". It conveys no size information.
>>>
>>> Except in the real world of course where pretty much everyone uses it to
>>> refer to 8 bits. But yes, you're right...
>>
>> Pretty much everyone use machines where octet, byte, uint8_t and char
>> are the same thing modulo signedness. But when you're writing C code
>> you have to acknowledge that it may be compiled for a machine where
>
> You don't have to do anything of the kind. It doesnt take a genius to
> assume the general truth when nothing else indicates otherwise.
>
> I do understand the reasoning - however one must keep it real. A Byte is
> 8 bits in 99.99% of places and meeting rooms. If we must be pedantic
> each and every time then that might be fine for c.l.c but not for most
> people - for others its tiresome pedantry designed to irritate.

For me it's a matter of clarity. If there is a discussion and there's
a hidden assumption that a char is eight bits, which other assumptions
are there? The C standard is a help in this respect -- even though it
sometimes forces you to consider some rare special cases.

>> this isn't true ... or somehow make it clear that you don't intend to
>> support exotic architectures.
>
> Or, and better, make it clear when you do.
>
> ie this code is designed to be multi platform and support multiple byte
> sizes.etc etc

Do you by chance have a Windows background? Mine is Unix. There it's
normal to try to write portable code, since there are so many
different processors in use, and you never know where your program
will end up running. Alignment restrictions, endianness, padding,
sizeof long ... those things change all the time[1].

That doesn't mean I always write portable code, or even document when
I don't. Not even when I break the subset of C determined by POSIX ...
but it's still my goal.

/Jorgen

[1] Not the CHAR_BIT aspect, though. IIRC POSIX requires an
architecture with 8-bit bytes.

[James Kuyper]

On 12/29/2013 03:32 PM, David Brown wrote:
...

> It's a matter of believability. Certainly some people believe in things
> that others find unlikely, which is fair enough. But if you were to say
> "I believe the moon is made of cheese", I would not believe that you

> believe that. Obviously sticking to old-fashioned definitions ...

I'm curious about your labeling of this definition as "old-fashioned". A
very large fraction of newly written C code is targeted to embedded
systems. I'm not sure how large that fraction is, but it's large enough
that, on one memorable occasion, I had considerable trouble convincing
one guy that it was less than 100%. Many of those embedded systems are
DSPs with 16 bit bytes. So implementations of C with bytes that are not
equivalent to octets is a very current issue.

> ... of a term

> like "byte" isn't quite that extreme - but if you say, without reference
> or additional qualification, that you believe a reference to a "byte" in
> current writing might reasonably refer to something other than 8 bits,
> then I would not take you literally.

So, you consider the definition of "byte" that is provided by the C
standard to be so thoroughly esoteric (is that the right word to cover
your objection?) that it would never occur to you that I might consider
that definition to be authoritative in the context of C code? Unless I
emphatically told you otherwise (as I am now doing), you:

> ... would assume you are

> exaggerating, joking, playing the devil's advocate, or otherwise trying
> to make a point in some way, or perhaps you have misread the question or

> mistyped the answer. ...

That seems like a rather extreme position to take. It's as if you were
actively resisting learning the fact (and it IS a fact) that there are
contexts where some people use the term with a different definition from
the one you're used to.
--
James Kuyper

[Keith Thompson]

Phil Carmody <thefatphi...@yahoo.co.uk> writes:
[...]

> BANG!!! i*i will be negative at some point.
> A wild stab in the dark, some point around i=46349.
>
> Possible solutions:
> (1) Generally - Use unsigned integer types for things you know can never
> be negative. (but take care to make sure those assumptions don't mess
> things up, loops that count down can often cause newbs problems.)
> (2) This particular case - Stop the sieving loop as soon as you're sure
> that no more composites can be sieved out. So don't loop i up to n, loop
> op to sqrt(n) instead, and then just dump the rest of the contents out
> in a trivial loop without sieving.

But don't compute sqrt(n) each time through the loop. Computing sqrt(n)
can be moderately expensive, and is likely to swamp the time you save by
doing fewer iterations. Either compute sqrt(n) once at the top of the
loop and save it in a variable (and watch out for floating-point
rounding issues), or change the logic so you compare i*i vs. n rather
than comparing i vs. sqrt(n).

[Keith Thompson]

David Brown <david...@hesbynett.no> writes:
[...]

> I have used processors with 16-bit "char", and no way to make an 8-bit
> type (except as a bitfield). Nowhere, in any of the documentation,
> manuals, datasheets, or anywhere else was there any reference to a
> "byte" that is not 8 bits. It made clear that a /char/ was 16 bits
> rather than the usual 8 bits, but they were never called "bytes".
>
> I haven't used such devices much - but the vast majority of people who
> use the term "byte" have never even heard of such devices, never mind
> used them.
>
> There are only two situations when "byte" does not automatically and
> unequivocally mean "8 bits" - one is in reference to ancient computer
> history (and documents from that era, such as network RFC's), and the
> other is extreme pedantry. There is a time and place for both of these
> - but you won't convince many people that you would ever /really/ think
> a reference to a "byte" meant anything other than 8 bits.
>
> (If you can give modern, or at least still-current, references to usage
> of "byte" for something other than 8 bits, then I will recant and blame
> the egg nog!.)
>
> A "char", as you say, has a well defined meaning - but not a well
> defined size.

As I'm sure you know, the ISO C standard uses the term "byte" to refer
to the size of type char, which is CHAR_BIT bits. CHAR_BIT is required
to be *at least* 8, but may be larger. I can't think of anything in the
standard that even implies that 8 is the preferred value.

And yes, I understand that there are real-world systems with CHAR_BIT >
8 (DSPs, mostly), though I haven't used a C compiler on any of them.

Even if CHAR_BIT were required to be exactly 8, I'd still prefer to
refer to CHAR_BIT rather than using the constant 8, since the macro name
makes it clearer just what I mean.

But if I have a need to write code that won't work unless CHAR_BIT==8,
I'll probably take a moment to ensure that it won't *compile* unless
CHAR_BIT==8. (Unless I'm working on existing code that has such
assumptions scattered through it; in that case, I probably won't bother.)

[David Brown]

On 30/12/13 00:41, James Kuyper wrote:
> On 12/29/2013 03:32 PM, David Brown wrote:
> ...
>> It's a matter of believability. Certainly some people believe in things
>> that others find unlikely, which is fair enough. But if you were to say
>> "I believe the moon is made of cheese", I would not believe that you
>> believe that. Obviously sticking to old-fashioned definitions ...
>
> I'm curious about your labeling of this definition as "old-fashioned". A
> very large fraction of newly written C code is targeted to embedded
> systems. I'm not sure how large that fraction is, but it's large enough
> that, on one memorable occasion, I had considerable trouble convincing
> one guy that it was less than 100%. Many of those embedded systems are
> DSPs with 16 bit bytes. So implementations of C with bytes that are not
> equivalent to octets is a very current issue.

I am an embedded programmer myself - with 8-bit, 16-bit and 32-bit
microcontrollers. I have used DSP's a little, but DSP programming is a
niche area. I don't have any hard numbers, but I think the percentage
of C code written for DSP's is very low, and getting lower as ordinary
microcontrollers replace them. There are lots of DSP devices sold - but
fewer people programming them.

Anyway, these devices do not have 16-bit "bytes" as such. Many types
have 16-bit or 32-bit "chars" - but they are not (normally) referred to
as "bytes". The exception, of course, is the C standards which define
"byte" to be the smallest addressable unit. (Some microcontrollers and
DSP's allow direct addressing of bits, but that uses compiler-specific
extensions to C.) I don't have any DSP datasheets or toolchain manuals
handy, so I am relying on memory here, but with the devices I used,
groups of 16 bits were never referred to as "bytes".

The word "byte" has several definitions, such as the one in the C (and
C++) standards, the one in the IEEE (I've forgotten the number)
standard, and the ones used by various computer manufacturers over the
decades. But the de facto definition used in almost all current
contexts is 8 bits. That is why I say other uses are old-fashioned. The
C standards are written in a rather specific style, with their own
specific definitions of terms that are often consistent with historical
usage rather than current usage. (Compare that to the Java standard,
which I believe defines a "byte" as 8 bits.)

>
>> ... of a term
>> like "byte" isn't quite that extreme - but if you say, without reference
>> or additional qualification, that you believe a reference to a "byte" in
>> current writing might reasonably refer to something other than 8 bits,
>> then I would not take you literally.
>
> So, you consider the definition of "byte" that is provided by the C
> standard to be so thoroughly esoteric (is that the right word to cover
> your objection?) that it would never occur to you that I might consider
> that definition to be authoritative in the context of C code? Unless I
> emphatically told you otherwise (as I am now doing), you:
>
>> ... would assume you are
>> exaggerating, joking, playing the devil's advocate, or otherwise trying
>> to make a point in some way, or perhaps you have misread the question or
>> mistyped the answer. ...
>
> That seems like a rather extreme position to take. It's as if you were
> actively resisting learning the fact (and it IS a fact) that there are
> contexts where some people use the term with a different definition from
> the one you're used to.
>

Fair enough - the context of C standards is a clear exception where
"byte" can mean more than 8 bits, and obviously that is a common case
here (although it is "esoteric" outside the world of c.l.c. and similar
forums).

But even here, how often does the issue of "char" possibly having more
than 8 bits come up when it makes a real-world, practical difference?
It is almost invariably when someone writes code that assumes chars are
8 bits, or assumes the existence of uint8_t, and then one of the
standards experts points out that this might not always be true. (I
don't mean this comment in a bad way - it is a useful thing to be
informed of these details.) And almost invariably, the code the OP is
writing will never be used on a system without 8-bit chars, and the OP
knows this.

And even in the context of machines with more than 8-bit chars, how
often are these referred to as "bytes" without a great deal of
qualification or context to avoid confusion?


Maybe I expressed myself a bit too strongly, but I would certainly be
surprised to read any reference to "byte" here that did not refer to
8-bit bytes, unless there was context to qualify it.

[David Brown]

From the N1570 draft of C11 standard (since I have it to hand):

byte
addressable unit of data storage large enough to hold any member of the
basic character set of the execution environment

I don't know /exactly/ what that means in a non-hosted environment
without any character set (as would be the case for most DSP's), but I
take it to mean the smallest directly addressable unit of storage of
size at least 8-bit (by the later definition of CHAR_BIT).

And I'll agree that these standards are current documents, though their
definition of "byte" is for consistency with historical versions of the
standards rather than for consistency with modern usage.

>
> And yes, I understand that there are real-world systems with CHAR_BIT >
> 8 (DSPs, mostly), though I haven't used a C compiler on any of them.
>

Yes, that's true - and I have used a C compiler for a couple of them.
But they don't refer to a 16-bit "char" as a "byte" (except as implied
by the C standards), precisely to avoid confusion. There are more than
enough sources of confusion when you have to work with such systems...

> Even if CHAR_BIT were required to be exactly 8, I'd still prefer to
> refer to CHAR_BIT rather than using the constant 8, since the macro name
> makes it clearer just what I mean.

Fair enough - clarity is important.

>
> But if I have a need to write code that won't work unless CHAR_BIT==8,
> I'll probably take a moment to ensure that it won't *compile* unless
> CHAR_BIT==8. (Unless I'm working on existing code that has such
> assumptions scattered through it; in that case, I probably won't bother.)
>

Absolutely. Usually I do that by using "uint8_t" (and occasionally
"int8_t") types - code that is dependent on CHAR_BIT == 8 will typically
have use of such types. And on the few occasions when I have been
unable to avoid working on DSP's with 16-bit (or even 32-bit) chars, I
have gone through all the code carefully to make sure it will work.

[Robert Wessel]

The standard doesn't allow an implementation "without any character
set"; the execution character set (which has about 100 characters)
must always be supported. You might not use it for anything, but it
has to be there if you want to call it a C implementation. That
would imply at least seven bit bytes.

In any event, the parenthetical on the definition of CHAR_BIT sums it
up: "number of bits for smallest object that is not a bit-field
(byte)" (which it then goes on to define as a minimum of eight, of
course).

[James Kuyper]

On 12/30/2013 06:22 AM, David Brown wrote:
> On 30/12/13 00:41, James Kuyper wrote:
>> On 12/29/2013 03:32 PM, David Brown wrote:
...

> The word "byte" has several definitions, such as the one in the C (and
> C++) standards, the one in the IEEE (I've forgotten the number)
> standard, and the ones used by various computer manufacturers over the
> decades. But the de facto definition used in almost all current
> contexts is 8 bits. That is why I say other uses are old-fashioned.

I don't follow that - it would only make sense if the de-facto usage had
already long since replaced the standard-defined meaning. The fact is
that both meanings have been in existence and in use at the same time
for a very long time. The de-facto usage is unambiguously the more
common one, but that's not because it has replaced the standard one. The
standard definition has never been widely used, but the same type of
people who used to use it in the appropriate contexts have continued to
use it in those contexts.
--
James Kuyper

[James Kuyper]

On 12/30/2013 06:35 AM, David Brown wrote:
...

> From the N1570 draft of C11 standard (since I have it to hand):
>
> byte
> addressable unit of data storage large enough to hold any member of the
> basic character set of the execution environment
>
> I don't know /exactly/ what that means in a non-hosted environment
> without any character set

The environment might not have any character set, but the C standard
requires that a conforming implementation for that environment support
the basic character set as defineed in section 5.2.1. The first use of
"basic character set" in that section is in italics, an ISO convention
indicating that it constitutes the definition of that term:

> A byte with
> all bits set to 0, called the null character, shall exist in the basic execution character set; it
> is used to terminate a character string.
> 3 Both the basic source and basic execution character sets shall have the following
> members: the 26 uppercase letters of the Latin alphabet
>
> A B C D E F G H I J K L M
> N O P Q R S T U V W X Y Z
>
> the 26 lowercase letters of the Latin alphabet
>
> a b c d e f g h i j k l m
> n o p q r s t u v w x y z
>
> the 10 decimal digits
>
> 0 1 2 3 4 5 6 7 8 9
>
> the following 29 graphic characters
>
> ! " # % & ' ( ) * + , - . / :
> ; < = > ? [ \ ] ^ _ { | } ~
>
> the space character, and control characters representing horizontal tab, vertical tab, and
> form feed.

A freestanding implementation is not required to support <stdio.h>,
which makes that character set relatively unimportant, but it still must
be defined, - each of those characters must be assigned a unique
encodings, character literals must have those values, and string
literals require the existence of arrays of char whose elements have
those values. There are, if I counted correctly, 92 members of the basic
character set, so it requires more than 7 bits to give each one a unique
encoding, so the implication is that a the addressable storage unit must
be at least 8 bits. This is also implied the requirements that SCHAR_MIN
<= -127, SCHAR_MAX >= 127, and UCHAR_MAX >= 255 (5.2.4.2.1p1).
--
James Kuyper

[gyl]

On Wed, 25 Dec 2013 23:46:47 -0500, Martin Ambuhl
<mam...@earthlink.net> wrote:

>On 12/25/2013 8:09 AM, Albert van der Horst wrote:
>
>> The program itself doesn't give any complaints with gcc 4.4
>> on a stable Debian.

>> It is a classical prime sieve.
>> I can't find any fault with it.
>

>At least the following is wrong:
>1. You did not #include <stdlib.h>, needed for atoi (which is a poor
>choice, any way)
>2. You are trying to printf a long int with a %d specifier
>3. You have failed to ask your compiler for an appropriate level of
>warnings.
>
>(2) probably explains your seg fault; (3) explains why gcc didn't complain.
>
when/why a printf will cause a segment fault?

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

[Keith Thompson]

James Kuyper <james...@verizon.net> writes:
[...]

> A freestanding implementation is not required to support <stdio.h>,
> which makes that character set relatively unimportant, but it still must
> be defined, - each of those characters must be assigned a unique
> encodings, character literals must have those values, and string
> literals require the existence of arrays of char whose elements have
> those values. There are, if I counted correctly, 92 members of the basic
> character set, so it requires more than 7 bits to give each one a unique
> encoding, so the implication is that a the addressable storage unit must
> be at least 8 bits. This is also implied the requirements that SCHAR_MIN
> <= -127, SCHAR_MAX >= 127, and UCHAR_MAX >= 255 (5.2.4.2.1p1).

92 distinct values can be represented in just 7 bits, so the definition
of the basic character set only implies CHAR_BIT >= 7. The actual
requirement that CHAR_BIT >= 8 is stated explicitly elsewhere in the
standard.

[Keith Thompson]

If you call printf, you need to call it correctly. Some errors, such as
passing something of the wrong type as the first argument, are
compile-time errors; others, such as passing a later argument with the
wrong format, needn't be caught by the compiler. The latter class of
errors result in *undefined behavior*. A segmentation fault is one
possible result.

If you want to print a long int value, you need to use the "%ld" format
(or something like it); "%d" requires an int argument.

Without looking at the code, I don't know whether that's what's causing
the symptom you're seeing, but you should certainly fix that problem.
You should also invoke gcc with options to enable more warnings, such as
"gcc -std=c99 -pedantic -Wall -Wextra -O3". (You might vary the
"-std=c99 -pedantic" options depending on what dialect of C you're
trying to use.)

[James Kuyper]

On 12/30/2013 11:12 AM, Keith Thompson wrote:
> James Kuyper <james...@verizon.net> writes:
> [...]
>> A freestanding implementation is not required to support <stdio.h>,
>> which makes that character set relatively unimportant, but it still must
>> be defined, - each of those characters must be assigned a unique
>> encodings, character literals must have those values, and string
>> literals require the existence of arrays of char whose elements have
>> those values. There are, if I counted correctly, 92 members of the basic
>> character set, so it requires more than 7 bits to give each one a unique
>> encoding, so the implication is that a the addressable storage unit must
>> be at least 8 bits. This is also implied the requirements that SCHAR_MIN
>> <= -127, SCHAR_MAX >= 127, and UCHAR_MAX >= 255 (5.2.4.2.1p1).
>
> 92 distinct values can be represented in just 7 bits, so the definition

> of the basic character set only implies CHAR_BIT >= 7. ...

You're right, of course - I wasn't thinking hard enough about what I was
writing.

> ... The actual

> requirement that CHAR_BIT >= 8 is stated explicitly elsewhere in the
> standard.

Specifically, 5.2.4.2.1p1, where CHAR_BIT is described as "number of
bits for smallest object that is not a bit-field (byte)".

It seems a little odd that "byte" is defined as being "large enough to
hold any member of the basic character set", when that requirement is
NOT the one that determines its minimum size. I had incorrectly
remembered the size as being determined by that requirement, which would
have rendered the requirement that CHAR_BIT >= 8 redundant.

[Martin Ambuhl]

In the case of his code, others have pointed out logical errors more
likely to cause a segfault. But, yes, printf can cause a segfault when
you misspecify the the lengths of arguments.

[James Kuyper]

On 12/30/2013 01:27 PM, Martin Ambuhl wrote:
...

> In the case of his code, others have pointed out logical errors more
> likely to cause a segfault. But, yes, printf can cause a segfault when
> you misspecify the the lengths of arguments.

Yes, but it's substantially less likely to malfunction in that
particular fashion when only one format specifier is present, and it
specifies a type that is probably no larger than the type of the only
argument. Malfunctions of other types are still quite likely, of course.

[Robert Wessel]

The basic character set for the execution environment includes several
additional control characters ("In the basic execution character set,
there shall be control characters representing alert, backspace,
carriage return, and new line). I think that pushes the total to 99
(52+10+29+space+7ctrl).

[James Kuyper]

>> be at least 8 bits. ...

That should have said 6 and 7 bits respectively. I should also have
mentioned that CHAR_BIT is explicitly required to be at least 8, which
is therefore the tighter constraint.

>> ... This is also implied the requirements that SCHAR_MIN

>> <= -127, SCHAR_MAX >= 127, and UCHAR_MAX >= 255 (5.2.4.2.1p1).
>
>
> The basic character set for the execution environment includes several
> additional control characters ("In the basic execution character set,
> there shall be control characters representing alert, backspace,
> carriage return, and new line). I think that pushes the total to 99
> (52+10+29+space+7ctrl).

That's why I said "if I counted correctly". I knew that 92 didn't sound
right. The basic character set includes

26 upper case letters
26 lower case letters
10 decimal digits
29 graphic characters
1 space character
4 control characters
==
96 characters

My count included the null character, which is only in the basic
execution character set (5.2.1p2), and didn't include the last two
categories.

The basic execution character set, the one referenced by the definition
of "byte", includes the null character and the three additional control
characters mentioned in the sentence you cited, bringing the total to an
even 100 characters.
--
James Kuyper

[christ...@cbau.wanadoo.co.uk]

On Friday, December 27, 2013 8:43:52 AM UTC, Bill Leary wrote:

> I've been at this since the late 70's. I've encountered bugs in C compilers
> four times. Three with the same compiler. And, once, in the "lseek"
> function that came with another compiler package. Yes, it took a long time
> to debug. And yes, they're memorable.

I once had to write

int fifteen = 15;

and replace a literal 15 in the code with fifteen to make the code work (after a compiler update).

[Kenny McCormack]

In article <80a477ea-728b-4e28...@googlegroups.com>,

Kiki will be by any minute now to point out that that compiler was not
standards-compliant.

And is thus OT in this newsgroup. Shame on you!

--
The scent of awk programmers is a lot more attractive to women than
the scent of perl programmers.

(Mike Brennan, quoted in the "GAWK" manual)

[glen herrmannsfeldt]

There are places in Fortran IV and Fortran 66 where variables are
allowed, but not constants. (The I/O list of WRITE statements,
for one.) That sometimes results in such variables.

One I remember from a C compiler was failing to compile ++
applied to a double variable. Presumably rare enough that it
wasn't caught in testing, but I had to change it so my program
would compile.

-- glen

[Jorgen Grahn]

On Mon, 2013-12-30, David Brown wrote:
...

> Anyway, these devices do not have 16-bit "bytes" as such. Many types
> have 16-bit or 32-bit "chars" - but they are not (normally) referred to
> as "bytes". The exception, of course, is the C standards which define
> "byte" to be the smallest addressable unit. (Some microcontrollers and
> DSP's allow direct addressing of bits, but that uses compiler-specific
> extensions to C.) I don't have any DSP datasheets or toolchain manuals
> handy, so I am relying on memory here, but with the devices I used,
> groups of 16 bits were never referred to as "bytes".

That matches my recollection (I've been programming Texas DSPs at two
quite diffeerent workplaces, around 1997 and in 2003 or so). IIRC you
tended to talk about "words" instead -- another rather fuzzy term
which in my mind translates to "the width which is a rough best match
for registers and memory accesses".

/Jorgen

[David Harmon]

On Thu, 26 Dec 2013 11:53:33 -0500 in comp.lang.c, James Kuyper
<james...@verizon.net> wrote,

>On 12/25/2013 11:46 PM, Martin Ambuhl wrote:
>...

>> Why is it that novice programmers always want to blame their compiler
>> for their own errors?
>
>They know, from a user perspective, that defective software is
>commonplace, so they suspect the compiler. They have not yet learned
>that the reason why defective software is commonplace is that it's very
>hard to write defect-free code, so they underestimate the likelihood
>that it's a mistake in their own code.

And they have examined their code carefully, and didn't see anything
wrong with it. That leaves the compiler by process of elimination.

[guinne...@gmail.com]

On Wednesday, 25 December 2013 13:09:30 UTC, Albert van der Horst wrote:
> I have the following program that gives consistently a segfault

<snip>

> for ( i=2; i<=n; i++)

Your problem lies here. The limit of the loop should be the truncated
(integer) square root of n, not n itself.

See https://en.wikipedia.org/wiki/Sieve_of_eratosthenes#Implementation

> int main( int argv, char** argc)

Although by no means wrong, this is an unusual choice of parameter
names for main(). By convention, the argument-count is usually
named 'argc' and the argument-values pointer 'argv'.

HTH,
Tony.

[Richard]

guinne...@gmail.com writes:

> On Wednesday, 25 December 2013 13:09:30 UTC, Albert van der Horst wrote:
>> I have the following program that gives consistently a segfault
>
> <snip>
>
>> for ( i=2; i<=n; i++)
>
> Your problem lies here. The limit of the loop should be the truncated
> (integer) square root of n, not n itself.
>
> See https://en.wikipedia.org/wiki/Sieve_of_eratosthenes#Implementation
>
>> int main( int argv, char** argc)
>
> Although by no means wrong, this is an unusual choice of parameter

You're too kind. It's totally "wrong" by any measure other than allowing
people to write crap unmaintainable code. That line would screw up loads
of people and cost countless man hours down the road. So it IS wrong imo.

> names for main(). By convention, the argument-count is usually
> named 'argc' and the argument-values pointer 'argv'.
>
> HTH,
> Tony.

--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

[Jorgen Grahn]

On Thu, 2014-01-09, Richard wrote:
> guinne...@gmail.com writes:
>
>> On Wednesday, 25 December 2013 13:09:30 UTC, Albert van der Horst wrote:

...

>>> int main( int argv, char** argc)
>>
>> Although by no means wrong, this is an unusual choice of parameter
>
> You're too kind. It's totally "wrong" by any measure other than allowing
> people to write crap unmaintainable code. That line would screw up loads
> of people and cost countless man hours down the road. So it IS wrong imo.

It's not wrong, but it's so close to wrong that it might as well been.
(And I think I commented on it last year, elsewhere in the thread.
I expect it to be fixed already.)

[Richard]

Jorgen Grahn <grahn...@snipabacken.se> writes:

> On Thu, 2014-01-09, Richard wrote:
>> guinne...@gmail.com writes:
>>
>>> On Wednesday, 25 December 2013 13:09:30 UTC, Albert van der Horst wrote:
> ...
>>>> int main( int argv, char** argc)
>>>
>>> Although by no means wrong, this is an unusual choice of parameter
>>
>> You're too kind. It's totally "wrong" by any measure other than allowing
>> people to write crap unmaintainable code. That line would screw up loads
>> of people and cost countless man hours down the road. So it IS wrong imo.
>
> It's not wrong, but it's so close to wrong that it might as well been.

ie its wrong. Lets not be silly here. Only an idiot would purposely swap
around the names of two pretty much industry standard main parameters.

> (And I think I commented on it last year, elsewhere in the thread.
> I expect it to be fixed already.)

ie it was fixed. Because it was wrong.

>
> /Jorgen

[Ken Brody]

On 1/10/2014 9:42 AM, Richard wrote:
> Jorgen Grahn <grahn...@snipabacken.se> writes:
>
>> On Thu, 2014-01-09, Richard wrote:
>>> guinne...@gmail.com writes:
>>>
>>>> On Wednesday, 25 December 2013 13:09:30 UTC, Albert van der Horst wrote:
>> ...
>>>>> int main( int argv, char** argc)
>>>>
>>>> Although by no means wrong, this is an unusual choice of parameter
>>>
>>> You're too kind. It's totally "wrong" by any measure other than allowing
>>> people to write crap unmaintainable code. That line would screw up loads
>>> of people and cost countless man hours down the road. So it IS wrong imo.
>>
>> It's not wrong, but it's so close to wrong that it might as well been.
>
> ie its wrong. Lets not be silly here. Only an idiot would purposely swap
> around the names of two pretty much industry standard main parameters.

It's a little wrong to say a tomato is a vegetable. It's very wrong to say
it's a suspension bridge.

[Kaz Kylheku]

On 2013-12-25, Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:
> The program itself doesn't give any complaints with gcc 4.4
> on a stable Debian.

^^^^^^

apt-get install valgrind

> It is a classical prime sieve.
> I can't find any fault with it.

You're joking, right?

How about making effective use of readily available tools.

Compiler's opinion: plenty wrong here!

$ gcc -Wall -ansi -pedantic -W -g sieve.c -o sieve
sieve.c: In function ‘main’:
sieve.c:41:5: warning: implicit declaration of function ‘atoi’ [-Wimplicit-function-declaration]
sieve.c:42:5: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long int’ [-Wformat]
sieve.c:40:9: warning: unused variable ‘i’ [-Wunused-variable]
sieve.c:38:15: warning: unused parameter ‘argv’ [-Wunused-parameter]
sieve.c:45:1: warning: control reaches end of non-void function [-Wreturn-type]

Validation with valgrind:

$ valgrind ./sieve 1231234
[.. snip ...]
==31965== Invalid write of size 1
==31965== at 0x8048519: fill_primes (sieve.c:33)
==31965== by 0x8048579: main (sieve.c:43)
==31965== Address 0x881002e9 is not stack'd, malloc'd or (recently) free'd

The offending line 33 is

for (j=i*i; j<=n; j+=i) composite[j] = 1;

suggesting you're blowing past the end of a the static array.

[Robert Wessel]

On Fri, 10 Jan 2014 11:02:25 -0500, Ken Brody <kenb...@spamcop.net>
wrote:

>On 1/10/2014 9:42 AM, Richard wrote:
>> Jorgen Grahn <grahn...@snipabacken.se> writes:
>>
>>> On Thu, 2014-01-09, Richard wrote:
>>>> guinne...@gmail.com writes:
>>>>
>>>>> On Wednesday, 25 December 2013 13:09:30 UTC, Albert van der Horst wrote:
>>> ...
>>>>>> int main( int argv, char** argc)
>>>>>
>>>>> Although by no means wrong, this is an unusual choice of parameter
>>>>
>>>> You're too kind. It's totally "wrong" by any measure other than allowing
>>>> people to write crap unmaintainable code. That line would screw up loads
>>>> of people and cost countless man hours down the road. So it IS wrong imo.
>>>
>>> It's not wrong, but it's so close to wrong that it might as well been.
>>
>> ie its wrong. Lets not be silly here. Only an idiot would purposely swap
>> around the names of two pretty much industry standard main parameters.
>
>It's a little wrong to say a tomato is a vegetable. It's very wrong to say
>it's a suspension bridge.

But the Supreme Court said it was a vegetable, how can calling it a
vegetable be wrong? ;-)

[Skybuck Flying]

When I saw this subject line the first thing I thought was:

"Probably a newb question/program".

The second thing was more funny:

"Everything because it was written in C :)"

Bye,
Skybuck.