Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Happy christmas

Reply
Thread Tools

Happy christmas

 
 
Old Wolf
Guest
Posts: n/a
 
      12-25-2007
On Dec 25, 12:37 pm, jacob navia <(E-Mail Removed)> wrote:
>
> Take, for instance, we all some day needed to read an entire
> file into RAM to process it. Why there isn't
>
> char *strfromfile(const char *file_name,const char *mode);
>
> As a holidays present, here it is.


Your code doesn't even work properly in anything except Windows

Great present!

> errno = ENOENT;
> errno = ENOMEM;


ENOENT and ENOMEM are not defined (it is implementation-specific
whether such things exist)

> if (strchr(mode,'b') == NULL) {
> char *src = result,*dst = result;
> while ((src - result) < l) {
> if (*src != '\r')
> *dst++ = *src;
> src++;
> }
> *dst = 0;


This code is Windows-specific.

This has got to be the dumbest snippet I've seen in a
while. If you open the file in text mode then the
implementation performs this newline conversion and
any other such conversions for you. Why reinvent
the wheel?



 
Reply With Quote
 
 
 
 
Malcolm McLean
Guest
Posts: n/a
 
      12-25-2007
"santosh" <(E-Mail Removed)> wrote in message
>
> And this particular task is also doable in standard C with no loss in
> functionality or efficiency. I understand that the Committee had an
> overall policy to include only those new functions in the Standard
> library that would be impossible or difficult to replicate in user
> code. This is opposite to the philosophy of the C++ Committee.
>

It's not a good policy.
For instance everyone can knock up a strcpy() in a matter of minutes. You
can even improve the ANSI version somewhat.
But if you are reading standard, workaday code, that is maybe manipulating a
user report in a protein program, its a big help if the calls are familiar
with you. You don't want to be distracted by

if( str_lsetsafe(fred, FREDLEN, jim, 0, -1) == ERRVAL)
goto genbufferror;

when all we're doing is setting fred equal to jim.


--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      12-25-2007
Flash Gordon wrote:
> Wouldn't it be more sensible to use the mode the user passes in?
>


No, because in text mode the standard doesn't guarantee that ftell and
fseek will work correctly!

>
> Using l as a variable name was a bad idea because it makes it harder to
> read the above line, or easier to miss-read it.
>


Yes, will change that to len

> Also you fail to allow for it reading fewer then the number of 1 byte
> members you specify. This can happen for a number of reasons.
>
>> goto ioerror;
>> result[l] = 0;
>> fclose(f);
>> if (strchr(mode,'b') == NULL) {
>> char *src = result,*dst = result;
>> while ((src - result) < l) {

>
> Hmm. You have an initialisation, a test, and an increment, wouldn't a
> for loop have been more natural?
>
>> if (*src != '\r')
>> *dst++ = *src;
>> src++;

>
> Since you have opened the file in binary mode and MacOS 9.x and earlier
> use '\r' as the line terminator you have just converted the file to one
> long line on some systems.
>


Yes, will not work in DS9000 and MAC os9.x Easy to change though.
There is no portable way to know what line separator the system uses.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      12-25-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
Nicely spotted. A memory leak. Will correct that.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      12-25-2007
santosh wrote:
> (E-Mail Removed) wrote:
>
>> On Dec 25, 1:37 am, jacob navia <(E-Mail Removed)> wrote:
>>> Why are C interfaces so low level?
>>>
>>> We discussed a bit about this in the thread about getting an URL from
>>> the internet.
>>>
>>> Take, for instance, we all some day needed to read an entire
>>> file into RAM to process it. Why there isn't
>>>
>>> char *strfromfile(const char *file_name,const char *mode);
>>>
>>> As a holidays present, here it is.
>>>
>>> [ snip ]
>>> Argument "mode" should be either "r" or "rb" for binary or text mode.
>>> This can be omitted in Unix systems, where this stupid distinction
>>> doesn't exist.
>>>
>>> If I do not find a "b" in the "mode" string I eliminate CRs from the
>>> string.
>>>
>>> NOTE: This function will not run in the DS9000

>> Why you never free() what you allocate?

>
> <snip>
>
> Because jacob almost always assumes a modern OS like Windows or a UNIX
> variant will clean up after the program.
>
> In general, even if the OS may recover the memory, I still prefer
> explicitly deallocating them. It better practise and stands up well to
> porting to other systems.
>


It was just a memory leak santosh...


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      12-25-2007
Malcolm McLean wrote:

> "santosh" <(E-Mail Removed)> wrote in message
>>
>> And this particular task is also doable in standard C with no loss in
>> functionality or efficiency. I understand that the Committee had an
>> overall policy to include only those new functions in the Standard
>> library that would be impossible or difficult to replicate in user
>> code. This is opposite to the philosophy of the C++ Committee.
>>

> It's not a good policy.


It depends. Going the other way and including everything except the
Kitchen sink, as the C++ people have done might also be criticised by
some.

> For instance everyone can knock up a strcpy() in a matter of minutes.
> You can even improve the ANSI version somewhat.


If my program would significantly benefit from the improvement in
functionality or speed, then I'd use the platform specific version,
over the stock one supplied with the library.

But this is somewhat rare. Usually if a function is available as a part
of a Standard library, you'd do well to use it.

> But if you are reading standard, workaday code, that is maybe
> manipulating a user report in a protein program, its a big help if the
> calls are familiar with you. You don't want to be distracted by
>
> if( str_lsetsafe(fred, FREDLEN, jim, 0, -1) == ERRVAL)
> goto genbufferror;
>
> when all we're doing is setting fred equal to jim.


True. Nevertheless the overall philosophy of C is for it to supply
minimal functionality and thereby preserve ease of portability and
efficiency. If you want an extensive Standard library, try C++, Java,
Perl, Python, Tcl and others.

 
Reply With Quote
 
publicforme@gmail.com
Guest
Posts: n/a
 
      12-25-2007
merry Christmas too.
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      12-25-2007
santosh wrote:
> Malcolm McLean wrote:
>
>> "santosh" <(E-Mail Removed)> wrote in message
>>> And this particular task is also doable in standard C with no loss in
>>> functionality or efficiency. I understand that the Committee had an
>>> overall policy to include only those new functions in the Standard
>>> library that would be impossible or difficult to replicate in user
>>> code. This is opposite to the philosophy of the C++ Committee.
>>>

>> It's not a good policy.

>
> It depends. Going the other way and including everything except the
> Kitchen sink, as the C++ people have done might also be criticised by
> some.
>

They didn't, they took the sensible path of standardising a container
and algorithms library that was in widespread use.

The next version will do much the same with the most widely used parts
of boot. It's a natural process of library evolution that the C
standard appears to have lost sight of.

If you want a true kitchen sink approach, try Java...

--
Ian Collins.
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      12-25-2007
jacob navia wrote:
> Flash Gordon wrote:
>

.... snip ...
>
>> Since you have opened the file in binary mode and MacOS 9.x and
>> earlier use '\r' as the line terminator you have just converted
>> the file to one long line on some systems.> >

>
> Yes, will not work in DS9000 and MAC os9.x Easy to change though.
> There is no portable way to know what line separator the system
> uses.


Yes there is. Just open the file in text mode (i.e. without the
"rb") and wait until you detect a '\n' in the stream. That is
exactly where a line separator occured.

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      12-25-2007
CBFalconer wrote:
> jacob navia wrote:
>> Flash Gordon wrote:
>>

> ... snip ...
>>> Since you have opened the file in binary mode and MacOS 9.x and
>>> earlier use '\r' as the line terminator you have just converted
>>> the file to one long line on some systems.> >

>> Yes, will not work in DS9000 and MAC os9.x Easy to change though.
>> There is no portable way to know what line separator the system
>> uses.

>
> Yes there is. Just open the file in text mode (i.e. without the
> "rb") and wait until you detect a '\n' in the stream. That is
> exactly where a line separator occured.
>

So What?

You think the function should discover each time
it is called the line separator?


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Christmas Clipart - Huge Christmas Graphics Package !!! xmanclick4 Python 0 02-14-2010 02:15 PM
Merry Christmas & A Happy New Year! Jay Wireless Networking 1 12-24-2005 09:49 PM
DVD Verdict reviews: ALL I WANT FOR CHRISTMAS, CARTOON NETWORK CHRISTMAS: YULETIDE FOLLIES, and more! DVD Verdict DVD Video 0 12-10-2004 10:10 AM
happy happy christmas showgun MCSE 26 12-17-2003 07:11 PM



Advertisments