Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Date: Wed, 17 Feb 1999 19:37:11 +0200
From: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>
Reply-To: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>
Message-ID: <17817.990217@is.lg.ua>
To: Corinna Vinschen <corinna DOT vinschen AT cityweb DOT de>, cygwin AT sourceware DOT cygnus DOT com
Subject: Re[2]: Cygwin B20 - fseek under gcc fails to reposition on text files
References: <36CA92B5 DOT 844635AA AT cityweb DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Corinna,

Corinna Vinschen <corinna DOT vinschen AT cityweb DOT de> wrote:

[]

CV> We have three possible choices:

CV> 1st: We are not performing the same errors as M$. We do our own, so we let
CV>      it as it is.

CV> 2nd: M$-compatible errors, so we let ftell count \n, too. This would result
CV>      in more often correct telling.

CV> 3rd: The full stdio code in newlib has to be changed. The buffer is used
CV>      anyway in binary mode, every call has to use new counting and
CV>      translation methods than the current one.
CV>      Because this has to be done _very_ cautious, it's a long time change.

CV> For the near future, I would prefer the second choice. Other opinions?

    Let me support 3rd way, in rather flamy passages, however.

    So, for more than twenty years MS maintains myth about "special
format" of text files of their systems. It's hardly believable. Since
my old XT I quite nicely handled any text files - be they Unix \xa,
Mac \xd, or "dos" \xd\xa . So there's nothing special to talk about
"special" format of text files. Most tools available handled any type,
and conversion between formats was quite feasible. With win32, such
problems are ceased at all - I don't have no line endings problems, no
encoding problems, even that unicode seams to be here.

   And here we come to most interesting questions - that fact that MS
maintains aforementioned myth is not surprising, but that myth is
carefully maintained by outside crew too! Just listen to those GNUers
telling us that text files here are "special" and they must dirty
workaround that! Just see peoples advocating data stream corruption on
most basic system level!

   But what if stop that play and acknowledge that some guys have done
quite well and it's useless to try to not notice that. \r\n textfiles
should be handled properly where they belong - e.g. in textutils, but
never in core system, leading just to corruption.

   So, what I argue:

1. Text/binary file notion on most basic, POSIX level should be
   abandoned.
2. That has nothing to do with stdio level - since default accessors for
   that level are single-character oriented, it doesn't hurt much
   stuffing single test there.

(Note that this indeed DJ Delorie's idea as of DJGPP lib, pushed further
to exterminating textuality on POSIX level at all)

3. All stuff working with textfiles and using POSIX level either should
   be taught accept any line-endings or reimplented in stdio.

4. Until then, there're fromdos/todos filters.


   And finally, from where all this stuff might be originated - it may
be done whatever wanted, but if, when writing to console we get clobbered
output without carrage returns, it doesn't cost a cent. That's where
myth of win32 speciality breaks down - Win32 console, as any other
console in cooked mode (Linux, say) performs implicit cr after lf,
when there's no explicit.

   Just run following (tested only on Win95/Win95OSR2 to be honest):

--------
#include <windows.h>

char str[]="\nline1\nline2\nline3\n";

void main()
{
  DWORD dummy;
  WriteFile(STD_OUTPUT_HANDLE,str,sizeof(str)-1,&dummy,NULL);
  WriteFile(STD_ERROR_HANDLE,str,sizeof(str)-1,&dummy,NULL);
}
--------


CV> Regards,
CV> Corinna


Best regards,
 Paul                            mailto:paul-ml AT is DOT lg DOT ua


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com