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

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

comp.lang.c@googlegroups.com

Today's topics:

* File scope code - 7 messages, 4 authors
http://groups.google.com/group/comp.lang.c/t/09a830902b61328a?hl=en
* Issue with printing a string - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/26e268149fdbfe14?hl=en
* Looking for external program invocations - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/4ab20cd6f143fa06?hl=en
* free c text book advice.. - 5 messages, 4 authors
http://groups.google.com/group/comp.lang.c/t/adf51d19d9b07faf?hl=en
* Motivation of software professionals - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/21a3fdec4dd53e6a?hl=en
* allocating m bytes dynamically - 5 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/3ce8c1090a941d64?hl=en
* Encoding Date/Time - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/0ad6871d063ac3e8?hl=en

==============================================================================
TOPIC: File scope code
http://groups.google.com/group/comp.lang.c/t/09a830902b61328a?hl=en
==============================================================================

== 1 of 7 ==
Date: Fri, Feb 5 2010 2:33 pm
From: Seebs

On 2010-02-05, bartc <bartc@freeuk.com> wrote:
> That's not what was suggested, which was a single, one-time initialisation
> function for the module.

Unless you are doing some serious crazy linker magic, the only way you can
achieve that is to have every function in the module check to see whether it's
called and if not, call it. Every time it's called.

There is crazy linker magic to let you bypass this, but it ain't pretty.

-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!

== 2 of 7 ==
Date: Fri, Feb 5 2010 2:46 pm
From: Kaz Kylheku

On 2010-02-05, sandeep <nospam@nospam.com> wrote:
> Hello friends
>
> Why is it not possible to have code (except declarations and MACROs) at
> file scope outside the body of any function?
>
> This code could initialize tables used by the module when it first gets
> loaded. Like a BEGIN block in Perl.

This feature appears in large and feature-laden offshoot dialect of C
known as C++.

C++ external definitions can have initializers which are not constant
expressions, and can call functions. C++ programs can also have external
definitions for objects whose constructors must be called.

All of that happens before the execution of main.

C++ does not solve the module ordering problem. If such initializations appear
in different translation units of the program, you don't know which ones happen
first. This ambiguity can be a source of bugs in C++ programs.

If you really need this feature, just use C++. Your code will be less portable
than if it were written in the 1990 dialect of C, but C++ is quite popular and
compiler availability is good.

== 3 of 7 ==
Date: Fri, Feb 5 2010 2:52 pm
From: Kaz Kylheku

On 2010-02-05, Seebs <usenet-nospam@seebs.net> wrote:
> On 2010-02-05, sandeep <nospam@nospam.com> wrote:
>>> Doesn't make sense, really. Modules aren't "loaded" in C the way they
>>> are in an interpreted language. There isn't a specific point at which a
>>> given ".c" file is "loaded" -- all of them have been already loaded in
>>> arbitrary and not necessarily consistent orders, and then the output of
>>> compilation joined together. Basically, if you want initializers, write
>>> them. There is some deep magic available to do this in a semi-automated
>>> way for some compilers.
>
>> I don't agree.
>
> You don't get a vote in whether or not to agree; I was describing how the
> language works.

You also said it doesn't make sense. That's a kind of vote. If you get a vote,
then sandeep gets a vote too.

== 4 of 7 ==
Date: Fri, Feb 5 2010 3:44 pm
From: "bartc"

"Seebs" <usenet-nospam@seebs.net> wrote in message
news:slrnhmp7b8.hld.usenet-nospam@guild.seebs.net...
> On 2010-02-05, bartc <bartc@freeuk.com> wrote:
>> That's not what was suggested, which was a single, one-time
>> initialisation
>> function for the module.
>
> Unless you are doing some serious crazy linker magic, the only way you can
> achieve that is to have every function in the module check to see whether
> it's
> called and if not, call it. Every time it's called.
>
> There is crazy linker magic to let you bypass this, but it ain't pretty.

Look at the original post: what was needed was an initialisation routine for
the module. That's called once as the module gets 'loaded'. That can do
runtime initialisations of file scope variables, before any of the functions
in the module are called.

But there is no explicit loading in C (unless the module is made into a
dynamic library). The same thing can be achieved by providing such an
init-function for the module, and arranging to have it called when the
entire application starts.

--
Bartc

== 5 of 7 ==
Date: Fri, Feb 5 2010 3:51 pm
From: Seebs

On 2010-02-05, bartc <bartc@freeuk.com> wrote:
> Look at the original post: what was needed was an initialisation routine for
> the module. That's called once as the module gets 'loaded'. That can do
> runtime initialisations of file scope variables, before any of the functions
> in the module are called.

I got the impression that the big focus wasn't "an initialization routine"
but "the ability to just put code in outside of any functions" -- that the
syntactic sugar of having this implicitly happen to code that wasn't in a
function was more significant to the request, and an initialization routine,
even one which magically "happened first", would not be an acceptable
substitute.

> But there is no explicit loading in C (unless the module is made into a
> dynamic library). The same thing can be achieved by providing such an
> init-function for the module, and arranging to have it called when the
> entire application starts.

Yes. The tricky part is how you do that; in particular, how do you make it
so the module itself can arrange to have the function called, without code
elsewhere having to know that you need that done?

The answer is some pretty hairy linker magic, and it ain't portable.

== 6 of 7 ==
Date: Fri, Feb 5 2010 4:27 pm
From: "bartc"

"Seebs" <usenet-nospam@seebs.net> wrote in message
news:slrnhmpbsj.mrg.usenet-nospam@guild.seebs.net...
> On 2010-02-05, bartc <bartc@freeuk.com> wrote:

>> But there is no explicit loading in C (unless the module is made into a
>> dynamic library). The same thing can be achieved by providing such an
>> init-function for the module, and arranging to have it called when the
>> entire application starts.
>
> Yes. The tricky part is how you do that; in particular, how do you make
> it
> so the module itself can arrange to have the function called, without code
> elsewhere having to know that you need that done?
>
> The answer is some pretty hairy linker magic, and it ain't portable.

To do it automatically, perhaps.

But if someone is writing such a module to be staticallly linked to an
application, then this will just be part of the API: call such and such
init-function before doing anything else.

(Perhaps call it load_modulename() to make it appear it's doing something
crucial. After all those other languages mentioned probably also have to
explicitly import or load a module before use.)

(The init-function will likely have logic to allow it to be called more than
once but only actually do the init once; and if it depends on other similar
modules to also call the init-function in those.)

--
Bartc

== 7 of 7 ==
Date: Fri, Feb 5 2010 5:11 pm
From: Ian Collins

bartc wrote:
>
> "Seebs" <usenet-nospam@seebs.net> wrote in message
> news:slrnhmpbsj.mrg.usenet-nospam@guild.seebs.net...
>> On 2010-02-05, bartc <bartc@freeuk.com> wrote:
>
>>> But there is no explicit loading in C (unless the module is made into a
>>> dynamic library). The same thing can be achieved by providing such an
>>> init-function for the module, and arranging to have it called when the
>>> entire application starts.
>>
>> Yes. The tricky part is how you do that; in particular, how do you make it
>> so the module itself can arrange to have the function called, without code
>> elsewhere having to know that you need that done?
>>
>> The answer is some pretty hairy linker magic, and it ain't portable.
>
> To do it automatically, perhaps.
>
> But if someone is writing such a module to be staticallly linked to an
> application, then this will just be part of the API: call such and such
> init-function before doing anything else.

The use of init (and finish) functions is common in drivers, where the
"application" truly is a module. The init function gets called when the
driver is loaded.

--
Ian Collins

==============================================================================
TOPIC: Issue with printing a string
http://groups.google.com/group/comp.lang.c/t/26e268149fdbfe14?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Feb 5 2010 2:37 pm
From: Seebs

On 2010-02-05, Nobody <nobody@nowhere.com> wrote:
> But a similar point applies here: glibc's <bits/string.h> has:
>
> #define strlen(str) \
> (__extension__ (__builtin_constant_p (str) \
> ? __builtin_strlen (str) \
> : __strlen_g (str)))
>
> So I would expect "#undef strlen" to change this.

You might, but apparently some of this stuff is also hardwired in the compiler
in some cases. It may vary with architecture, though.

extern int strcpy(char *, char *);
int main(void) {
return 0;
}

gcc says:

t.c:1: warning: conflicting types for built-in function `strcpy'

So how about:

extern unsigned int strlen(const char *);
int main(void) {
return strlen("foo");
}

gcc produces:

main:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
andl $-16, %esp
movl $0, %eax
subl %eax, %esp
movl $3, %eax
leave
ret

So, yes, it's gcc, not the headers.

craaaaazy stuff, huh.

== 2 of 2 ==
Date: Fri, Feb 5 2010 7:43 pm
From: Keith Thompson

Michael Foukarakis <electricdelta@gmail.com> writes:
> On Feb 4, 10:13 pm, "Default User" <defaultuse...@yahoo.com> wrote:
>> Michael Foukarakis wrote:
>> > On Feb 4, 2:54 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> > > Michael Foukarakis wrote:
>> > > > On Feb 4, 12:08 pm, Richard Heathfield <r...@see.sig.invalid>
>> > > > wrote:
>> > > >> Michael Foukarakis wrote:
>> > > > Indeed. Discussions also need arguments;
>>
>> > > <sigh> Not so's you'd notice.
>>
>> > Worth putting effort into, nonetheless. Trolls get tired, grow up, or
>> > die, eventually.
>>
>> They get tired much faster if you ignore them.
>
> And miss all the fun? :'(

Yes, *please*, do us all a favor and miss the fun.

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

==============================================================================
TOPIC: Looking for external program invocations
http://groups.google.com/group/comp.lang.c/t/4ab20cd6f143fa06?hl=en
==============================================================================

== 1 of 3 ==
Date: Fri, Feb 5 2010 3:08 pm
From: markhobley@hotpop.donottypethisbit.com (Mark Hobley)

I have some open source software packages that were written in C by a third
party, they make use of external programs. For the purposes of security
auditing, and for making appropriate fixes, I need to locate all instances
within the code, where an external program is being called.

What keywords or functions would I need to locate?

I am thinking of using grep to simply search for the function names. Would
that be sufficient, or is it possible that function names are split across
several lines, making it possible for some instances to be missed during the
audit?

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

== 2 of 3 ==
Date: Fri, Feb 5 2010 4:33 pm
From: Flash Gordon

Mark Hobley wrote:
> I have some open source software packages that were written in C by a third
> party, they make use of external programs. For the purposes of security
> auditing, and for making appropriate fixes, I need to locate all instances
> within the code, where an external program is being called.
>
> What keywords or functions would I need to locate?

The standard one is system, but pretty much all systems where this is
possible have other functions as well.

> I am thinking of using grep to simply search for the function names. Would
> that be sufficient, or is it possible that function names are split across
> several lines, making it possible for some instances to be missed during the
> audit?

Well, if you are considering possibly malicious source code then they
could play games with #define to build the token 'system' from
components, or they could use inline assembler, or all sorts of other
things.
--
Flash Gordon

== 3 of 3 ==
Date: Fri, Feb 5 2010 6:08 pm
From: markhobley@hotpop.donottypethisbit.com (Mark Hobley)

Flash Gordon <smap@spam.causeway.com> wrote:
> The standard one is system, but pretty much all systems where this is
> possible have other functions as well.

This is Linux.
>
> Well, if you are considering possibly malicious source code then they
> could play games with #define to build the token 'system' from
> components, or they could use inline assembler, or all sorts of other
> things.

Thanks for that.

In these cases, the code is not malicious in this case, it is just badly
written open source code, that I need to track down the external software
calls, for the purpose of making changes.

So far ... I need to look for system, asm, and exec. Is there anything else?
(I know that I have to audit the libraries too).

Can the commands ever cross line boundaries causing failure of detection by
grep, such as in the example below? Or is this not possible?

syst
em("causedamage.sh");

In future instances, I may need to be able to track down tokenized system
call. Presumably, I could achieve detection of this via buildwrappers
on the preprocessor.

I may also need to look for utilization of specific library calls that cause
invocation of external commands. What strategy would be best for this (again
for future reference, of course).

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

==============================================================================
TOPIC: free c text book advice..
http://groups.google.com/group/comp.lang.c/t/adf51d19d9b07faf?hl=en
==============================================================================

== 1 of 5 ==
Date: Fri, Feb 5 2010 3:10 pm
From: Richard Heathfield

Mark Hobley wrote:
> jacob navia <jacob@nospam.org> wrote:
>> This is a misleading comment. That book is very old. No mention of
>> standard C as it is used today. All standard references are to the
>> obseolete 89 standard.
>
> I like C89,

So do I.

> and I think it is good practice to use it.

So do I.

> It is compatible with
> existing C compilers.

Or rather, existing C compilers are compatible with it. :-)

> Why break compatiblity with existing compilers by
> introducing things that do not work with existing compilers?

I can summarise the answer to that question in three words:
functionality, functionality, functionality.

Sometimes you just gotta. If your spec requires you to implement a
feature that cannot be achieved using only standard C89, then obviously
you have to go outside standard C89 in order to implement that spec. You
can wrap it up in a separate module, sure (and you'd be well-advised to
do that), but the non-standardinositude is still in there somewhere.

Portability has benefits and costs. Sometimes, portability is not the
overriding concern.

Nevertheless, write portable code when you can, and wrappers when you can't.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 2 of 5 ==
Date: Fri, Feb 5 2010 3:10 pm
From: jacob navia

Mark Hobley a écrit :
> jacob navia <jacob@nospam.org> wrote:
>> This is a misleading comment. That book is very old. No mention of
>> standard C as it is used today. All standard references are to the
>> obseolete 89 standard.
>
> I like C89, and I think it is good practice to use it. It is compatible with
> existing C compilers. Why break compatiblity with existing compilers by
> introducing things that do not work with existing compilers?
>
> Mark.
>

Because if we would follow your advice nothing would ever get better
because we would break compatibility with old bugs.

You use 64 bit data?

You need long long and C99.

You need variable length arrays?

You need C99.

Etc!

Nobody is *forcing* you to use C99.

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

== 3 of 5 ==
Date: Fri, Feb 5 2010 4:31 pm
From: Keith Thompson

jacob navia <jacob@nospam.org> writes:
> Mark Hobley a écrit :
>> jacob navia <jacob@nospam.org> wrote:
>>> This is a misleading comment. That book is very old. No mention of
>>> standard C as it is used today. All standard references are to the
>>> obseolete 89 standard.
>>
>> I like C89, and I think it is good practice to use it. It is compatible with
>> existing C compilers. Why break compatiblity with existing compilers by
>> introducing things that do not work with existing compilers?
>>
>
> Because if we would follow your advice nothing would ever get better
> because we would break compatibility with old bugs.

How so? If a programmer chooses to use C90, how does that prevent an
implementer from implementing C99?

> You use 64 bit data?
>
> You need long long and C99.

Probably so. There's nothing preventing a C90 compiler from providing
a 64-bit integer type (and calling it "long", or even "short"), but
unlike C99 it's not required. (If you're desperate you can build
64-bit arithmetic on top of something narrower, but I wouldn't do that
unless it was absolutely necessary.)

> You need variable length arrays?
>
> You need C99.

You never actually *need* variable length arrays. They're a
convenience, not a requirement. (And malloc has the advantage that
it lets you detect allocation failures.)

> Etc!
>
> Nobody is *forcing* you to use C99.
>
> You can still use Turboc in msdos if you want to.

Or you can use any modern C implementation in C90 mode, or just
choose not to use C99-specific features. C90 isn't limited to
obsolete compilers.

And most well-written C90 code *is* C99 code; it just doesn't use
all the features of the newer standard.

We all program in subsets of whatever language we're using.
If I don't happen to need setjmp and longjmp, for example,
I presume nobody is going to criticize me for not using them.
And if, hypothetically, a number of popular implementations didn't
support them properly, I'm guessing nobody would object if I warned
people about that and suggested workarounds. (I'm not aware of
any implementations that don't handle setjmp and longjmp properly;
as I said, that's a hypothetical example.)

But anyone who chooses to use a subset of C99 that excludes
C99-specific features, and who explains the perfectly valid reasons
for doing so (without insisting that anyone else should do the same)
is flamed, ridiculed, and falsely accused of waging a campaign
against C99.

[This thread is cross-posted to comp.lang.c, comp.lang.c.moderated,
and comp.std.c. I've dropped all but comp.lang.c.]

== 4 of 5 ==
Date: Fri, Feb 5 2010 5:56 pm
From: Richard Heathfield

jacob navia wrote:
> Mark Hobley a écrit :
>> jacob navia <jacob@nospam.org> wrote:
>>> This is a misleading comment. That book is very old. No mention of
>>> standard C as it is used today. All standard references are to the
>>> obseolete 89 standard.
>>
>> I like C89, and I think it is good practice to use it. It is
>> compatible with
>> existing C compilers. Why break compatiblity with existing compilers by
>> introducing things that do not work with existing compilers?
>>
>> Mark.
>>
>
> Because if we would follow your advice nothing would ever get better
> because we would break compatibility with old bugs.
>
> You use 64 bit data?
>
> You need long long and C99.

C89 imposes no upper limit on the width of integer types. Implementors
are perfectly free to make, say, long int 64 bits wide (or wider still,
if they want).

> You need variable length arrays?
>
> You need C99.

Or malloc.

>
> Etc!

Etc.

> Nobody is *forcing* you to use C99.

Right.

> You can still use Turboc in msdos if you want to.

Sure. Or you can use the very latest edition of Microsoft Visual C. And
you won't find C99 conformance at either end of that spectrum.

== 5 of 5 ==
Date: Fri, Feb 5 2010 7:14 pm
From: markhobley@hotpop.donottypethisbit.com (Mark Hobley)

jacob navia <jacob@nospam.org> wrote:

> Nobody is *forcing* you to use C99.

Well, in theory no .. but open source is a problem, because people keep
using code that only works on a specific compiler (although admittedly that
problem is more to do with GCC than C99.)

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

==============================================================================
TOPIC: Motivation of software professionals
http://groups.google.com/group/comp.lang.c/t/21a3fdec4dd53e6a?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Feb 5 2010 3:08 pm
From: Seebs

On 2010-02-05, Jedrin <jrubiando@gmail.com> wrote:
> If money was the only motivating factor wouldn't we all want to be
> wall street bankers instead ?

If we thought we could make more money at it than we could programming. I
don't think I could. Comparative advantage ftw!

== 2 of 2 ==
Date: Fri, Feb 5 2010 2:33 pm
From: yf110@vtn1.victoria.tc.ca (Malcolm Dew-Jones)

Jedrin (jrubiando@gmail.com) wrote:

: If money was the only motivating factor wouldn't we all want to be
: wall street bankers instead ?

Perhaps we all do - but until we get that chance...

==============================================================================
TOPIC: allocating m bytes dynamically
http://groups.google.com/group/comp.lang.c/t/3ce8c1090a941d64?hl=en
==============================================================================

== 1 of 5 ==
Date: Fri, Feb 5 2010 5:01 pm
From: 2005

On Feb 5, 5:44 am, Richard Heathfield <r...@see.sig.invalid> wrote:
> Ben Bacarisse wrote:
> > Richard Heathfield <r...@see.sig.invalid> writes:
>
> <snip>
>
>
>
> >>>> if(ptr != NULL)
> >>>> {
> >>>> int i = 0;
> >>>> while(i < MAX)
> >>>> {
> >>>> ptr[i] = i;
> >>>> }
>
> > Presumably i should be changed in this loop. This may explain, in
> > part, the odd "timeout" message the OP is getting.
>
> Oh yeah. Oops.
>
> Sometimes I do wish people wouldn't take me quite so literally. :-)
>
> --
> Richard Heathfield <http://www.cpax.org.uk>
> Email: -http://www. +rjh@
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line vacant - apply within

Thanks, Santosh, Richard & Ben,

The issue was missing "i++" - I had actually replaced the "m" with
MAX;
BTW: what is the deal about size_t num_ints = MAX; // MAX is already
defined to be 10 - the code runs w/o that line too.
Also what is this "size_t"?
Also why do you say "malloc() and friends" ?

You can click the link to see/run the code: http://codepad.org/8Z8Q3pdo

Thanks

== 2 of 5 ==
Date: Fri, Feb 5 2010 5:14 pm
From: 2005

On Feb 4, 12:02 am, santosh <santosh....@gmail.com> wrote:
> 2005 wrote:
> > 1) If I want to allocate m bytes dynamically would the following do?
> > 2) What is the purpose of the for loop here - assign initial value?
>
> > int main(void)
> > {
> > int m = 100;
> > int *ptr = (int *) malloc(m);
>
> Note that in C you don't have to cast the return value of malloc/
> calloc/realloc, since conversion to and from a void pointer is
> implicit.

Thanks Santosh - but why at
http://en.wikipedia.org/wiki/Malloc

they are doing it and kind of making a standard ?

Another question I have is that should
ptr[i] = i; this be ptr[i] = 0; instead?

== 3 of 5 ==
Date: Fri, Feb 5 2010 5:14 pm
From: Andrew Poelstra

On 2010-02-06, 2005 <FW3006@sbcglobal.net> wrote:
>
> The issue was missing "i++" - I had actually replaced the "m" with
> MAX;
> BTW: what is the deal about size_t num_ints = MAX; // MAX is already
> defined to be 10 - the code runs w/o that line too.

Variables hold values. They're safe. Macros, on the other hand,
make programmers feel nervous sometimes. That's probably all it
was.

> Also what is this "size_t"?

size_t is an unsigned integer type that can hold the size of
any object in your C program. It's also what malloc() takes
as an argument.

> Also why do you say "malloc() and friends" ?
>

There is also realloc(), which takes a malloc()'d pointer and
returns one to a bigger size - though be careful when it fails
that you don't lose the original!

And there is calloc(), which allocates memory and 0's it out,
though you again should be careful because for pointers and
floating point values sometimes all 0's is not actually zero.

And there is free(), which is kinda a friend of malloc().

> You can click the link to see/run the code: http://codepad.org/8Z8Q3pdo
>

Your code is here (it's hard to use two programs at once):

> #include <stdlib.h>
> #define MAX 10
>
> int main(void)
> {
>
>
> // size_t num_ints = MAX;

// comments are dangerous on Usenet because sometimes lines wrap
around and then your code doesn't compile. And some people here
(including myself) don't use compiler modes that support them.

> int *ptr = malloc(MAX * sizeof (int));

You can use sizeof directly on *ptr, like so:
int *ptr = malloc(MAX * sizeof *ptr);
This saves you a potential bug if you decide ptr should actually
point to longs or shorts or size_ts or something.

> if(ptr != NULL)
> {
> int i = 0;
> while(i < MAX)
> {
> ptr[i] = i;
> printf ("ptr[%d] = %d\n", i, ptr[i]);
> i++;
>
> }
> /* use those values in other ways
> if you like, and then, when you
> have finished, call free():
> */
>
> }
> free(ptr);
> return 0;
>
> }
>

I'm a little tired, but it looks to me that this code is A-OK.
Congratulations!

== 4 of 5 ==
Date: Fri, Feb 5 2010 5:18 pm
From: Andrew Poelstra

On 2010-02-06, 2005 <FW3006@sbcglobal.net> wrote:
> On Feb 4, 12:02�am, santosh <santosh....@gmail.com> wrote:
>> 2005 wrote:
>> > 1) If I want to allocate m bytes dynamically would the following do?
>> > 2) What is the purpose of the for loop here - assign initial value?
>>
>> > int main(void)
>> > {
>> > � � � � int m = 100;
>> > � � � � int *ptr = (int *) malloc(m);
>>
>> Note that in C you don't have to cast the return value of malloc/
>> calloc/realloc, since conversion to and from a void pointer is
>> implicit.
>
> Thanks Santosh - but why at
> http://en.wikipedia.org/wiki/Malloc
>
> they are doing it and kind of making a standard ?

Because on Wiki you get a number of silly psuedo-programmers who
use C++ syntax without realizing that they are in fact using a C
function. (In C++ the cast is necessary. But in C++ the malloc()
is not. :P)

>
> Another question I have is that should
> ptr[i] = i; this be ptr[i] = 0; instead?

It depends on what you're doing. I missed the context of your
question, but if you just want to zero out an array of ints
you can save yourself some time and cycles by just using
calloc() in the first place:

int *ptr = calloc(m, sizeof *ptr);

Which will give you the right number of bytes and set them
all to zero.

== 5 of 5 ==
Date: Fri, Feb 5 2010 5:23 pm
From: Seebs

On 2010-02-06, 2005 <FW3006@sbcglobal.net> wrote:
> they are doing it and kind of making a standard ?

"When using C, this is considered bad practice; it is redundant under the C
standard."

They explicitly disclaim that. However, it would be needed in C++, and since
the code there seems to be intended to work as either...

==============================================================================
TOPIC: Encoding Date/Time
http://groups.google.com/group/comp.lang.c/t/0ad6871d063ac3e8?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Feb 5 2010 6:17 pm
From: "BGB / cr88192"

"Richard Heathfield" <rjh@see.sig.invalid> wrote in message
news:g4adncjTougnS_fWnZ2dnUVZ8ludnZ2d@bt.com...
> jacob navia wrote:
>> Richard Heathfield a écrit :
>>> PNP wrote:
>>>> I need to fine the current date/time add x hours & y minutes to
>>>> it. I then need to send it through IPC to a different process which
>>>> can read this & find the sent time.
>>>>
>>>> What is smallest number of bytes I need for sending this data?
>>>> i.e. How many bytes is that data guaranteed to fit in?
>>>
>>> Let's assume that our calendar will survive indefinitely in its present
>>> form, and that you are happy with a granularity no finer than seconds.
>>>
>>> An instant in time, then, can be described by these components: seconds
>>> (0-59 - we'll ignore leap-seconds); minutes (0-59); hours (0-23); days
>>> (0-30); months (0-11); and years.
>>>
>>> Leaving years aside for the time being: if we wish to store mdhms as
>>> separate data elements, we need a minimum of 26 bits. If we are prepared
>>> to combine them, maybe we can save some bits. We could simply store the
>>> number of seconds in a year, which, in a leap year, could be
>>> approximately 31557600. This value can be stored in 25 bits. Okay, so we
>>> saved one single bit. (Is that a worthwhile saving? Probably not. But
>>> you asked for the smallest number of bytes, and that suggests that we
>>> should try to economise on every possible bit.)
>>>
>>> Now let's think about years. If we try to fit a year value into 7 bits
>>> (which is tempting, since it gives us 32 bits altogether), the biggest
>>> number we can have is 127 (in which case the smallest would be 0). We
>>> could say "okay, let's use that to describe the year range 2010 to
>>> 2137", in which case the answer to your question is 32 bits. But if we
>>> want something more durable than that, or if we need to extend into the
>>> past, then we will need more bits.
>>>
>>> If you're happy with a 128-year range, then, you will need 32 bits,
>>> which is guaranteed to fit into 4 bytes, because a byte is guaranteed to
>>> be at least 8 bits wide. Bytes can be wider than that, though, so you
>>> might be able to squeeze 32 bits into fewer bytes on some systems.
>>>
>>
>> If we just store the date as the number of seconds since a given instant
>> (say January First 2000 0:00) we can store 136 years in an unsigned 32
>> bits, 9 years more than using Mr Heathfield's schema
>>
>> :-)
>
> And starting at 1/1/2000 knocks 10 years off, which means that your schema
> expires before mine. :-)
>
> But yes, you're right in general.
>
> Having said that, if we bite the bullet, forget the minbits requirement,
> and settle for 64 bits, we can not only make decoding a little bit easier
> but also massively extend the range:
>
> bits 0-5: second
> bits 6-11: minute
> bits 12-16: hour
> bits 17-21: day
> bits 22-25: month
> bits 26-63: year
>
> 38 bits for the year gives us a range of 0 to 274877906943, which "ought
> to be enough for anybody".
>
> <snip>
>

we can also just use the unix timestamp format, but put the unix timestamp
in the middle:
16 bits for a fractional second, making it accurate to around 15us;
+16 bits to the year, giving a signed range of +-2228224 years (from 1970)
or so...

this also makes it trivial to convert to/from unix timestamps within the
"valid" range.

also possible is to add ~20 bits to the second (and thus only ~12 to the
year), which is similarly, not particularly difficult to convert...

> --
> Richard Heathfield <http://www.cpax.org.uk>
> Email: -http://www. +rjh@
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line vacant - apply within

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

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

Friday, February 5, 2010

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

No comments:

Post a Comment