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

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

comp.lang.c@googlegroups.com

Today's topics:

* Idiotic programming style edicts - 8 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/99bc3aa427fc7518?hl=en
* Does GCC optimize variadic functions to death? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/00b2bccdde28fde4?hl=en
* segmentation fault. - 8 messages, 6 authors
http://groups.google.com/group/comp.lang.c/t/45d8cb9f7ea45c55?hl=en
* Container library (continued) - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/3763649cc890efcc?hl=en
* a hunk of not-very-portable code I've been working on - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/24988ee765b75811?hl=en
* Is it good to use char instead of int to save memory? - 4 messages, 3
authors
http://groups.google.com/group/comp.lang.c/t/40bfc7048b74630b?hl=en

==============================================================================
TOPIC: Idiotic programming style edicts
http://groups.google.com/group/comp.lang.c/t/99bc3aa427fc7518?hl=en
==============================================================================

== 1 of 8 ==
Date: Thurs, Mar 18 2010 3:22 pm
From: Keith Thompson

BruceS <bruces42@hotmail.com> writes:
[...]
> You've made clear what I was pointing out less directly. The lack
> of // comments is only when strictly adhering to the C90 (I keep
> calling it "C89"; are the two terms equivalent or am I just getting it
> wrong?) standard. Patrick's point is well taken, that these auto-
> terminating comments can help avoid certain errors. Of course, that
> would also avoid some of the humor in the early post.

Yes, C89 and C90 are (two documents that describe) the same language.
ANSI published the first C standard in 1989. ISO adopted ANSI's
standard in 1990; they added some non-normative introductory material
and renumbered the sections (ANSI sections 3 and 4 are ISO sections
6 and 7), but the text is otherwise unchanged. ANSI officially
adopted the ISO C90 standard shortly thereafter.

There was a 1995 amendment that added some relatively minor features.

The 1999 standard was issued directly by ISO (and ANSI adopted it).
There have been three Technical Corrigenda since then (folded
into <http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf>,
which isn't *quite* 100% official but it's close enough). Work is
in progress on C201X.

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

== 2 of 8 ==
Date: Thurs, Mar 18 2010 3:42 pm
From: Ben Bacarisse

Keith Thompson <kst-u@mib.org> writes:
about C standards:
<snip>
> The 1999 standard was issued directly by ISO (and ANSI adopted it).
> There have been three Technical Corrigenda since then (folded
> into <http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf>,
> which isn't *quite* 100% official but it's close enough).

I thought there had been only two TCs. Not that it really matters how
many there are, but if there is a third I can't find it and I'd like
to have a look.

> Work is in progress on C201X.

--
Ben.

== 3 of 8 ==
Date: Thurs, Mar 18 2010 3:54 pm
From: Keith Thompson

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
> about C standards:
> <snip>
>> The 1999 standard was issued directly by ISO (and ANSI adopted it).
>> There have been three Technical Corrigenda since then (folded
>> into <http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf>,
>> which isn't *quite* 100% official but it's close enough).
>
> I thought there had been only two TCs. Not that it really matters how
> many there are, but if there is a third I can't find it and I'd like
> to have a look.

Definitely three.

Go to <http://webstore.ansi.org/> and enter "9899" as the document
number; all three TCs are available as free downloads.

The C99 standard itself is available for the low low price of $275,
$30, $349, or $235, depending on which ADD TO CART button you click.
(I think I paid $18 for my copy).

== 4 of 8 ==
Date: Thurs, Mar 18 2010 4:09 pm
From: Larry__Weiss

Mensanator wrote:
> On Mar 18, 2:43 pm, Keith Thompson <ks...@mib.org> wrote:
>> BruceS <bruce...@hotmail.com> writes:
>>
>> [...]
>>
>>> <OT> AIUI, C++ accepts /* */ multiline comments without artificially
>>> terminating said comments at the end of line. I don't have a C++
>>> Standard in front of me, so I can't confirm that it isn't simply an
>>> artifact of environments in which I've written C++, but I'm relatively
>>> confident that these work the same as in C. </OT>
>> In both C and C++, a comment that begins with /* is not
>> "artificially" terminated at the end of the line. Instead, it's
>> "artificially" terminated by the next */. (In other words, I'm
>> not sure what's so artificial about it.)
>>
>>> According to The C Standard, 6.4.9p2, C allows comments that *do*
>>> automatically terminate at the end of the line, just as this style of
>>> comment works in C++.
>> [...]
>>
>> Yes, both C and C++ now permit comments introduced by // and
>> terminated by the end of the line. These were introduced in BCPL,
>> one of C's distant ancestors from the 1960s. But they were dropped
>> from C, and only reintroduced by the 1999 ISO C standard (which
>> superseded the 1990 ISO C standard, which itself superseded the
>> de facto standard of Kernighan & Ritchie's book). C++ has always
>> supported // comments.
>>
>> Today, most C compilers fully support at least the C90 standard,
>> but only a subset of the C99 standard. // comments are very widely
>> supported. On the other hand, they can be rejected if you choose
>> to invoke your C compiler in a strict C90-conforming mode, or if
>> you're using a sufficiently old compiler, so /*...*/ comments are
>> arguably more portable. // comments can also cause problems in
>> Usenet posts; implicit line wrapping can introduce syntax errors.
>>
>> (Most people here in comp.lang.c already know this stuff; I'm posting
>> it mostly for the benefit of those in alt.folklore.computers
>
> Hey! Some of us folklorists actually DO know how to program.
>

At least we think we remember that we know how to program.
And some of us still demonstrate it by actually programming from time to time.

Some of us wonder why we need all of these languages...
http://en.wikipedia.org/wiki/List_of_programming_languages

- Larry

== 5 of 8 ==
Date: Thurs, Mar 18 2010 4:20 pm
From: Ben Bacarisse

Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>> about C standards:
>> <snip>
>>> The 1999 standard was issued directly by ISO (and ANSI adopted it).
>>> There have been three Technical Corrigenda since then (folded
>>> into <http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf>,
>>> which isn't *quite* 100% official but it's close enough).
>>
>> I thought there had been only two TCs. Not that it really matters how
>> many there are, but if there is a third I can't find it and I'd like
>> to have a look.
>
> Definitely three.

So there are.

> Go to <http://webstore.ansi.org/> and enter "9899" as the document
> number; all three TCs are available as free downloads.

Thanks. I tried to find it on WG14's web pages and could see only
two. The main page does talk about TC3 but there is no text for it.
It turns out you can get it from the ISO as well: http://www.iso.org

> The C99 standard itself is available for the low low price of $275,
> $30, $349, or $235, depending on which ADD TO CART button you click.
> (I think I paid $18 for my copy).

! The last time I tried to get the older C90 from the BSI it was 400
pounds sterling.

--
Ben.

== 6 of 8 ==
Date: Thurs, Mar 18 2010 4:42 pm
From: Larry__Weiss

Ben Bacarisse wrote:
> I thought there had been only two TCs. Not that it really matters how
> many there are, but if there is a third I can't find it and I'd like
> to have a look.
>

http://www.open-std.org/jtc1/sc22/wg14/www/standards.html

- Larry

== 7 of 8 ==
Date: Thurs, Mar 18 2010 4:45 pm
From: Dave Hansen

On Mar 18, 11:58 am, "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
> In article <hnt5bs22...@news4.newsguy.com>, jmfbahciv@aol (jmfbahciv)
> writes:
>
> > <grin> My language is MACRO-10. JMF was always tickled whenever
> > he assembled some code because MACRO would report a "successful"
> > assembly with the comment "No errors detected". Think about it. ;-)
>
> "As far as we know, the system has never had an undetected error."

I'm reminded of the hypothetical "conforming" C implementation that,
no matter what is provided for input, displays the message "The input
may contain one or more errors", and emits a dummy program similar (or
identical) to Unix "true". Could be implemented with a shell script.

I'm also reminded of the arguments whether such an implementation was
truly conforming or not, but I don't want to go there...

Regards,

-=Dave

== 8 of 8 ==
Date: Thurs, Mar 18 2010 5:58 pm
From: Mensanator

On Mar 18, 6:09 pm, Larry__Weiss <l...@airmail.net> wrote:
> Mensanator wrote:
> > On Mar 18, 2:43 pm, Keith Thompson <ks...@mib.org> wrote:
> >> BruceS <bruce...@hotmail.com> writes:
>
> >> [...]
>
> >>> <OT> AIUI, C++ accepts /* */ multiline comments without artificially
> >>> terminating said comments at the end of line. I don't have a C++
> >>> Standard in front of me, so I can't confirm that it isn't simply an
> >>> artifact of environments in which I've written C++, but I'm relatively
> >>> confident that these work the same as in C. </OT>
> >> In both C and C++, a comment that begins with /* is not
> >> "artificially" terminated at the end of the line. Instead, it's
> >> "artificially" terminated by the next */. (In other words, I'm
> >> not sure what's so artificial about it.)
>
> >>> According to The C Standard, 6.4.9p2, C allows comments that *do*
> >>> automatically terminate at the end of the line, just as this style of
> >>> comment works in C++.
> >> [...]
>
> >> Yes, both C and C++ now permit comments introduced by // and
> >> terminated by the end of the line. These were introduced in BCPL,
> >> one of C's distant ancestors from the 1960s. But they were dropped
> >> from C, and only reintroduced by the 1999 ISO C standard (which
> >> superseded the 1990 ISO C standard, which itself superseded the
> >> de facto standard of Kernighan & Ritchie's book). C++ has always
> >> supported // comments.
>
> >> Today, most C compilers fully support at least the C90 standard,
> >> but only a subset of the C99 standard. // comments are very widely
> >> supported. On the other hand, they can be rejected if you choose
> >> to invoke your C compiler in a strict C90-conforming mode, or if
> >> you're using a sufficiently old compiler, so /*...*/ comments are
> >> arguably more portable. // comments can also cause problems in
> >> Usenet posts; implicit line wrapping can introduce syntax errors.
>
> >> (Most people here in comp.lang.c already know this stuff; I'm posting
> >> it mostly for the benefit of those in alt.folklore.computers
>
> > Hey! Some of us folklorists actually DO know how to program.
>
> At least we think we remember that we know how to program.
> And some of us still demonstrate it by actually programming from time to time.
>
> Some of us wonder why we need all of these languages...
> http://en.wikipedia.org/wiki/List_of_programming_languages

Oo, they even got Seed7 listed.

Would you believe Seed7 actually has a function named "bigCLit"?
(Perhaps the author isn't up on American slang. I know he's European
because he spoke of not living on the same continent.)

But where's BrainFuck?

I certainly don't wonder why.

>
> - Larry

==============================================================================
TOPIC: Does GCC optimize variadic functions to death?
http://groups.google.com/group/comp.lang.c/t/00b2bccdde28fde4?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 18 2010 3:46 pm
From: Keith Thompson

Elmar <elmar.krieger@gmail.com> writes:
[...]
>>However, IIRC in x64 functions with variable argument
>>lists go on the stack just like in x86, and only functions with fixed
>>argument lists get the (faster) register-based calling convention.
>
> This would certainly help, but I fear it can't be done: C allows
> implicit declaration, so the caller doesn't know that he's calling a
> variadic function, and thus cannot choose a stack-based calling
> convention.
[...]

In C90, if you call a function with no visible declaration, it's
assumed to take a fixed number of arguments of the (promoted) type(s)
you passed it and return a result of type int. Attempting to call a
variadic function with no visible prototype (not just a declaration;
the compiler has to see the "...") invokes undefined behavior.

So yes, a conforming C90 compiler can use different calling
conventions for variadic and non-variadic functions.

On the other hand, this would break (incorrect) programs that call
printf() without the requires "#include <stdio.h>" -- including the
first program in K&R1. I think many implementers have chosen to keep
consistent calling conventions for backward compatibility.

==============================================================================
TOPIC: segmentation fault.
http://groups.google.com/group/comp.lang.c/t/45d8cb9f7ea45c55?hl=en
==============================================================================

== 1 of 8 ==
Date: Thurs, Mar 18 2010 4:19 pm
From: Vandana

Hello All,

Can anyone please explain why I ma getting segmentation fault in the
following program?

struct employee {
char *name;
struct {
int apmt;
int zip;
} addr;
};

struct employee * populate_employee(char *name, int apt, int zip) {
struct employee *emp;
emp->name = name;
emp->addr.apmt = apt;
emp->addr.zip = zip;

return emp;
}

int main() {

struct employee *emp1;

printf("From the main\n");
emp1 = populate_employee("tom", 5, 90);
printf("address of emp1 is %u\n", emp1);

printf("Values from emp1 %s, %d %d\n", emp1->name, emp1->addr.apmt,
emp1->addr.zip);
return 0;
}

If I remove the printf "From the main" then the program seg faults,
otherwise, the program executes but ends with seg fault.

Thanks for your help!

== 2 of 8 ==
Date: Thurs, Mar 18 2010 4:30 pm
From: Ben Bacarisse

Vandana <nairvan@gmail.com> writes:

> Can anyone please explain why I ma getting segmentation fault in the
> following program?
>
>
> struct employee {
> char *name;
> struct {
> int apmt;
> int zip;
> } addr;
> };
>
> struct employee * populate_employee(char *name, int apt, int zip) {
> struct employee *emp;
> emp->name = name;
> emp->addr.apmt = apt;
> emp->addr.zip = zip;

emp is a pointer but where does it point? Leaving emp uninitialised
means that you can't use emp->anything. To fix this, you need to
decide how you want to manage these objects. The function could be
passed a pointer to a struct to fill in, or you could choose to
dynamically allocate a struct employee using malloc.

> return emp;
> }

<snip>
--
Ben.

== 3 of 8 ==
Date: Thurs, Mar 18 2010 5:38 pm
From: pete

Vandana wrote:
> Hello All,
>
> Can anyone please explain why I ma getting segmentation fault in the
> following program?
>
>
> struct employee {
> char *name;
> struct {
> int apmt;
> int zip;
> } addr;
> };
>
> struct employee * populate_employee(char *name, int apt, int zip) {
> struct employee *emp;
> emp->name = name;
> emp->addr.apmt = apt;
> emp->addr.zip = zip;
>
> return emp;
> }
>
> int main() {
>
> struct employee *emp1;
>
> printf("From the main\n");
> emp1 = populate_employee("tom", 5, 90);
> printf("address of emp1 is %u\n", emp1);
>
> printf("Values from emp1 %s, %d %d\n", emp1->name, emp1->addr.apmt,
> emp1->addr.zip);
> return 0;
> }
>
> If I remove the printf "From the main" then the program seg faults,
> otherwise, the program executes but ends with seg fault.

#include <stdio.h>

struct employee {
char *name;
struct {
int apmt;
int zip;
} addr;
};

void populate_employee
(struct employee *emp, char *name, int apt, int zip)
{
emp->name = name;
emp->addr.apmt = apt;
emp->addr.zip = zip;
}

int main(void)
{
struct employee empA;
struct employee *emp1 = &empA;

printf("From the main\n");
populate_employee(emp1, "tom", 5, 90);
printf("address of emp1 is %p\n", (void *)emp1);
printf("Values from emp1 %s, %d %d\n",
emp1->name, emp1->addr.apmt, emp1->addr.zip);
return 0;
}

--
pete

== 4 of 8 ==
Date: Thurs, Mar 18 2010 5:34 pm
From: Hamiral

pete wrote:
> #include <stdio.h>
>
> struct employee {
> char *name;
> struct {
> int apmt;
> int zip;
> } addr;
> };
>
> void populate_employee
> (struct employee *emp, char *name, int apt, int zip)
> {
> emp->name = name;
> emp->addr.apmt = apt;
> emp->addr.zip = zip;
> }

I think this is still dangerous.
What happens if the value passed to parameter name isn't a literal
string, but a dynamically allocated pointer to char, and gets freed
after the call to populate_employee() ?

I would do something like this :

#define NAME_MAX_LEN 50
struct employee {
char name[NAME_MAX_LEN];
struct {
int apmt;
int zip;
} addr;
};

void populate_employee
(struct employee *emp, char *name, int apt, int zip)
{
strncpy(emp->name, name, strlen(name), NAME_MAX_LEN);
emp->name[NAME_MAX_LEN - 1] = '\0';
emp->addr.apmt = apt;
emp->addr.zip = zip;
}

Assuming name is a properly null terminated string, and adding proper
#include's.

Ham (hoping he didn't make any mistake ;))

== 5 of 8 ==
Date: Thurs, Mar 18 2010 5:50 pm
From: "bartc"

"Hamiral" <hamiral@hamham.com> wrote in message
news:4ba2c69c$0$21807$426a74cc@news.free.fr...
> pete wrote:

>> void populate_employee
>> (struct employee *emp, char *name, int apt, int zip)
>> {
>> emp->name = name;
>> emp->addr.apmt = apt;
>> emp->addr.zip = zip;
>> }
>
> I think this is still dangerous.
> What happens if the value passed to parameter name isn't a literal string,
> but a dynamically allocated pointer to char, and gets freed after the call
> to populate_employee() ?
>
> I would do something like this :
>
> #define NAME_MAX_LEN 50

The 50 might be a problem. Most people's names will be less than 50, so
you're wasting space. Then every so often there will be someone with a name
longer than 50, and it will be truncated.

Maybe better to allocate the space locally, of the exact length needed, and
store a copy of the name.

Or insist name is suitable for storing in the record. So the caller
allocates the space, or points to where the name is currently stored.

--
Bartc

== 6 of 8 ==
Date: Thurs, Mar 18 2010 6:34 pm
From: Vandana

Thanks to all.

== 7 of 8 ==
Date: Thurs, Mar 18 2010 7:02 pm
From: Ben Bacarisse

Hamiral <hamiral@hamham.com> writes:
<snip>
> I would do something like this :
>
> #define NAME_MAX_LEN 50
> struct employee {
> char name[NAME_MAX_LEN];
> struct {
> int apmt;
> int zip;
> } addr;
> };
>
> void populate_employee
> (struct employee *emp, char *name, int apt, int zip)
> {
> strncpy(emp->name, name, strlen(name), NAME_MAX_LEN);

Some thing is wrong here. strncpy takes three arguments. I think you
intended to NAME_MAX_LEN as the third and last argument, though I
slightly prefer:

strncpy(emp->name, name, sizeof emp->name);

> emp->name[NAME_MAX_LEN - 1] = '\0';
> emp->addr.apmt = apt;
> emp->addr.zip = zip;
> }

<snip>
--
Ben.

== 8 of 8 ==
Date: Thurs, Mar 18 2010 7:10 pm
From: Seebs

On 2010-03-18, Vandana <nairvan@gmail.com> wrote:
> Can anyone please explain why I ma getting segmentation fault in the
> following program?

Yes.

> struct employee * populate_employee(char *name, int apt, int zip) {
> struct employee *emp;
> emp->name = name;

Where is "emp" pointing when you execute this line? Did you, for
instance, point it *at* anything?

Why, no, you didn't. It's garbage. It may or may not point anywhere
valid, and what it points at may or may not be important.

You might want to look into malloc().

-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: Container library (continued)
http://groups.google.com/group/comp.lang.c/t/3763649cc890efcc?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Mar 18 2010 7:03 pm
From: Seebs

On 2010-03-18, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> In this case, though, it doesn't seem to be. On the other hand... I
>> don't know that we ever need to have one that doesn't take at least one
>> argument. Because we pretty much always want an aux() type thing.

> I don't follow. Can you say a bit more...

Basically, any API like this for callbacks should almost always have
an extra parameter to every function, even functions which "take no
arguments", for passing sideband/auxiliary data.

So instead of
list_count(container);
it should be
list_count(container, aux);
where "aux" is a void * interpreted however a given kind of container
wants to interpret it.

== 2 of 3 ==
Date: Thurs, Mar 18 2010 7:23 pm
From: Ben Bacarisse

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

> On 2010-03-18, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>> In this case, though, it doesn't seem to be. On the other hand... I
>>> don't know that we ever need to have one that doesn't take at least one
>>> argument. Because we pretty much always want an aux() type thing.
>
>> I don't follow. Can you say a bit more...
>
> Basically, any API like this for callbacks should almost always have
> an extra parameter to every function, even functions which "take no
> arguments", for passing sideband/auxiliary data.
>
> So instead of
> list_count(container);
> it should be
> list_count(container, aux);
> where "aux" is a void * interpreted however a given kind of container
> wants to interpret it.

Sure. I think that is widely know. I had no idea you were talking
about callbacks. I thought you were talking about there being no need
for a fix for the __VA_ARGS__ problem in the macro I proposed. At
least I though you comment had something to do with the macro.

You can't be talking about the container operations themselves (which are
what my suggested macro calls) -- your example call has no auxiliary
data argument (quote correctly so in my opinion since it does not need
one).

[Can I suggest you to keep a little more context when you reply? No
one reading your reply could know what was being discussed when you
claimed that "we pretty much always want an aux() type thing".]

--
Ben.

== 3 of 3 ==
Date: Thurs, Mar 18 2010 8:05 pm
From: Seebs

On 2010-03-19, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Seebs <usenet-nospam@seebs.net> writes:
>> Basically, any API like this for callbacks should almost always have
>> an extra parameter to every function, even functions which "take no
>> arguments", for passing sideband/auxiliary data.
>>
>> So instead of
>> list_count(container);
>> it should be
>> list_count(container, aux);
>> where "aux" is a void * interpreted however a given kind of container
>> wants to interpret it.

> Sure. I think that is widely know. I had no idea you were talking
> about callbacks. I thought you were talking about there being no need
> for a fix for the __VA_ARGS__ problem in the macro I proposed. At
> least I though you comment had something to do with the macro.

I think it does. The fact that there must always be at least one more
argument means that we can use the , __VA_ARGS__ thing and expect it to
work, because there will always be at least one argument.

> You can't be talking about the container operations themselves (which are
> what my suggested macro calls) -- your example call has no auxiliary
> data argument (quote correctly so in my opinion since it does not need
> one).

Sure it does. (container, aux).

> [Can I suggest you to keep a little more context when you reply? No
> one reading your reply could know what was being discussed when you
> claimed that "we pretty much always want an aux() type thing".]

Not a bad idea. :)

==============================================================================
TOPIC: a hunk of not-very-portable code I've been working on
http://groups.google.com/group/comp.lang.c/t/24988ee765b75811?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 18 2010 7:14 pm
From: Seebs

On 2010-03-18, Flash Gordon <smap@spam.causeway.com> wrote:
> Your date/time formats in psuedolog.c (and hence probably the rest of
> the code) are somewhat US-centric... "%x %X" could be useful.

There's some of that, although I thought I'd made sure %x %X was at
least one of the accepted formats.

> I don't have the energy this evening to review things properly.

No worries, I mostly just posted it 'cuz I had a blast working on it,
and I thought it was pretty cool that my employer was willing to give
it away free.

Today's project has been adding support for emulating chroot(). It's
working in very light testing, but not all the way there yet. (Once
that's done, we'll stop using fakechroot. I then have one other thing,
a local hunk called "fakepasswd", to emulate, and we'll have reduced
the complexity of a large chunk of our build system dramatically.)

There's a fair amount of Very Non Portable Magic there, but the
fundamental guts of that hunk of work is a moderately generalizable
question. Imagine that you want to wrap some existing code such that,
say, a given value is automatically appended to strings it produces,
or removed from strings handed to it. How do you do this? Who owns
any newly allocated storage? etc.

==============================================================================
TOPIC: Is it good to use char instead of int to save memory?
http://groups.google.com/group/comp.lang.c/t/40bfc7048b74630b?hl=en
==============================================================================

== 1 of 4 ==
Date: Thurs, Mar 18 2010 8:19 pm
From: Thad Smith

Dr Malcolm McLean wrote:
> On 18 Mar, 19:52, jamm <nos...@nomail.net> wrote:
>> On an 8 bit uC with 128 bytes of SRAM, where char is 8 bit and int is 16
>> bit, yes char is what you're going to want to use. You would usually avoid
>> larger types for performance/memory reasons unless you really need an int.
>> Then use an int.
>>
> On such a machine a program than runs in 100 bytes of memory is
> usually as useful and cost-ecffective as one that runs in 50.

I have no idea what that statement means. Having 128 bytes of RAM and running
in 100 bytes are two different things -- one is normally data memory, the other
code memory. Processors with a few hundred bytes of RAM typically have several
kilobytes of non-volatile code memory.

The question for those processors isn't how small you can make the program, but
rather whether it fits at all and how much data it can handle. Or the question
is how expensive a processor do we need for a given job?

> However, yes, this would be a circumstance in which char for small
> integers is appropriate. In fact on such compilers int is often, non-
> conformingly, 8 bits and long is 16 bits.

This is at least one such non-conforming compiler, but most compilers for 8-bit
processors support ints and longs that are conforming in size.

--
Thad

== 2 of 4 ==
Date: Thurs, Mar 18 2010 7:40 pm
From: spinoza1111

On Mar 19, 4:53 am, Dr Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> On 18 Mar, 17:32, spinoza1111 <spinoza1...@yahoo.com> wrote:> On Mar 18, 11:07 pm, Dr Malcolm McLean
>
> > <malcolm.mcle...@btinternet.com> wrote:
> > > On 18 Mar, 13:25, "bartc" <ba...@freeuk.com> wrote:
>
> > > > I would guess the OP had a lower bound of 0 in mind, wouldn't you? Unless
> > > > there's a one in a thousand chance he's working with 9-bit chars.
>
> > > Zero? Danagerous Saracen magic. The lower bound should be one.
>
> > Malcolm!! Are congratulations in order, old fellow? Did you complete
> > your PhD? If so: my sincere compliments. If not, my best wishes.
>
> Veteran readers of comp.lang.c will have noticed a change in my
> moniker. I'm Dr Malcolm McLean now.

Congratulations. Some people here think that academic qualifications
aren't as important as subservience to management and backstabbing
coworkers. I don't.

== 3 of 4 ==
Date: Thurs, Mar 18 2010 7:41 pm
From: Ian Collins

On 03/19/10 04:19 PM, Thad Smith wrote:
> Dr Malcolm McLean wrote:
>> On 18 Mar, 19:52, jamm <nos...@nomail.net> wrote:
>>> On an 8 bit uC with 128 bytes of SRAM, where char is 8 bit and int is 16
>>> bit, yes char is what you're going to want to use. You would usually
>>> avoid
>>> larger types for performance/memory reasons unless you really need an
>>> int.
>>> Then use an int.
>>>
>> On such a machine a program than runs in 100 bytes of memory is
>> usually as useful and cost-ecffective as one that runs in 50.
>
> I have no idea what that statement means. Having 128 bytes of RAM and
> running in 100 bytes are two different things -- one is normally data
> memory, the other code memory. Processors with a few hundred bytes of
> RAM typically have several kilobytes of non-volatile code memory.
>
> The question for those processors isn't how small you can make the
> program, but rather whether it fits at all and how much data it can
> handle. Or the question is how expensive a processor do we need for a
> given job?
>
>> However, yes, this would be a circumstance in which char for small
>> integers is appropriate. In fact on such compilers int is often, non-
>> conformingly, 8 bits and long is 16 bits.
>
> This is at least one such non-conforming compiler, but most compilers
> for 8-bit processors support ints and longs that are conforming in size.

Agreed, I don't think I've ever used a compiler for an 8 bit micro where
int wasn't a conforming size. Which is why 8 bit types are often used
for small integers or counters

--
Ian Collins

== 4 of 4 ==
Date: Thurs, Mar 18 2010 7:43 pm
From: spinoza1111

On Mar 19, 3:25 am, Sjouke Burry <burrynulnulf...@ppllaanneett.nnll>
wrote:
> dspfun wrote:
> > Hi,
>
> > Is it recommended to use char instead of int for variables that you
> > know never will contain a value larger than 255? A small example
> > follows:
>
> > #include <stdio.h>
> > int main(void)
> > {
> > //int i = 1;
> > char i = 1; //is this better than previous line?
> > printf("i=%d\n",i);
> > return 0;
> > }
>
> > What are the pros and cons of using char instead of int when values
> > will not exceed 255?
>
> > Brs,
> > Markus
>
> I only once did that in an astro program that held data
> about several millions of stars, where each byte saved made a
> huge difference.
> In all other cases, dont do it.

By the end of the IBM 1401's useful life, I was "squozing" more and
more data into its 8K memory using an extrabit which was intended to
demarcate operands to get a 7 bit rather than 6 bit word.

A bit later, I acquired a Sinclair by post from Britain, plugged it
in, and it started to smoke (American power, British machine). After
the fire department left and the smoke had cleared, it still worked
and used storage most elegantly. It ran Basic in 2K.

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

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

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

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

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

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

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

twitter

Thursday, March 18, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts