ChangeLog entry:
2010-08-19 Pedro Izecksohn
* endian.h [_BSD_SOURCE || ! _POSIX_SOURCE] (htobe16, htobe32)
(htobe64, be16toh, be32toh, be64toh, htole16, htole32, htole64)
(le16toh, le32toh, le64toh): Macros defined.
I modified endian.h again:
*** /usr/include
--- Corinna Vinschen wrote:
>
> For this patch, given that it is just a bunch of rather obvious
> defines, I don't think we have to treat the patch as significant.
I do not think that these macros are obvious. I think that I was
there when these macros were first implemented at 1987: I talked wi
As this thread went nowhere, I searched for the BSD code:
http://svn.freebsd.org/viewvc/base/stable/8/sys/sys/endian.h?revision=199583&view=markup
It uses x to represent the variable as I did; but it also casts the variable.
I think that casting is not desirable because I like to see warnin
--- I wrote:
>> The x glyph represents the different ways to represent the same number:
>> ...
>> I thought to use (i) of integer, but its glyph does not remember the
>> proverb about Rome.
--- Corinna Vinschen asked:
> You mean "What have the Romans ever done for us?"
"All roads lead to Rome."
> Umm - did you copy straight from glibc's endian.h? That's a no-no;
> cygwin generally doesn't want to borrow LGPL sources to avoid any
> licensing questions (borrowing from BSD is okay, on the other hand).
> You would have to implement things from scratch from a documentation
> page, or copy fro
--- Eric Blake wrote:
>
> Umm - did you copy straight from glibc's endian.h? That's a no-no;
> cygwin generally doesn't want to borrow LGPL sources to avoid any
> licensing questions (borrowing from BSD is okay, on the other hand).
> You would have to implement things from scratch from a document
--- I wrote:
> Defines macros for to convert the endianness of 16, 32 and 64 bits
> integer types.
>
> diff -c /usr/include/endian.orig.h /usr/include/endian.h
My previous diff is wrong. The right one follows:
*** /usr/include/endian.orig.h Mon Apr 12 14:09:58 2010
--- /usr/include/endian.h
--- Eric Blake wrote:
> Christopher Faylor wrote:
>> I wrote:
>>> I hope this list accepts attachments.
>>
>> It does but the list mind-reading gizmo is on the fritz.
>
> Translation - a ChangeLog entry justifying your changes, a diff in
> unified or context format (-u or -c) rather than the defau
I hope this list accepts attachments.
endian.h.diff
Description: Binary data
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
--- Larry Hall wrote:
>
> Type "mount" and hit return. Does that answer your question?
> Just a little harmless redirection.
$ mount
C:/cygwin-1.7/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin-1.7/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin-1.7 on / type ntfs (binary,auto)
C: on /cygdri
I wrote a small C++ application:
http://www.izecksohn.com/pedro/c++/biggest/
that exhibits an unwanted behavior on Cygwin:
./biggest.exe -m -n -1 -d / > Cygwin\ files
head Cygwin\ files
822 /lib/gcc/i686-pc-cygwin/4.3.4/cc1plus.exe
822 /usr/lib/gcc/i686-pc-cygwin/4.3.4/cc1plus.exe
76672
I, Pedro Izecksohn wrote:
> Robert Pendell wrote:
>>
>> I was unable to reproduce this bug on 1.7. Compiled using GCC 4.3.4
>> on 1.7.0-62. Gave exit code 130 every time. I used your test case to
>> do the test.
>
> May be I did not express myself well:
>
Robert Pendell wrote:
>
> I was unable to reproduce this bug on 1.7. Compiled using GCC 4.3.4
> on 1.7.0-62. Gave exit code 130 every time. I used your test case to
> do the test.
May be I did not express myself well:
When ctrl c is pressed, it always give exit code 130. The
inconsistenci
Larry Hall wrote:
> I, Pedro Izecksohn, wrote:
>>
>> The default behavior is not always the same. I also got:
>> ferror (stdin):
>> and
>> ferror (stdin): Interrupted system call
>> and the expected behavior of just the exit code 130.
>>
>
r...@turion ~/programming/c/sigint
$ cat test.c
#include
#include
int main ()
{
printf ("Press Control c\n");
char buffer [3];
char *fgets_returned = fgets (buffer, sizeof buffer, stdin);
if (!fgets_returned)
{
if (ferror (stdin))
{
perror ("ferror (stdin)");
return
To initialize wchar_t wc=(wchar_t)0; may also help.
On Tue, Jul 28, 2009 at 6:56 AM, Andy Koppe wrote:
> 2009/7/28 Pedro Izecksohn:
>> The bug is in O.P.'s code as &s is not being passed to mbrtowc.
>
> From http://www.opengroup.org/onlinepubs/009695399/functions/mbr
The bug is in O.P.'s code as &s is not being passed to mbrtowc.
I'm on Ubuntu. I do not have Cygwin here.
I should consume some calories before trying to debug anything.
On Tue, Jul 28, 2009 at 6:14 AM, Corinna
Vinschen wrote:
> On Jul 27 22:56, Andy Koppe wrote:
>> I've encountered what l
From the "Linux Programmer’s Manual" (release 3.15 of the Linux man-pages):
"If the n bytes starting at s do not contain a complete multibyte
character, mbrtowc() returns (size_t) -2."
On Mon, Jul 27, 2009 at 6:56 PM, Andy Koppe wrote:
> I've encountered what looks like a bug in mbrtowc's han
Just to point out (as probably I'll solve it myself later):
$ tail make_check_outerr
make[1]: Entering directory `/opt/build/i686-pc-cygwin/winsup/cygwin'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/opt/build/i686-pc-cygwin/winsup/cygwin'
make[1]: Entering directory `/opt
--- Jacob Jacobson wrote:
> Perhaps this went unnoticed. Reposting it. I am still having
> problems building cygwin dll. Has anyone seen this error?
>
>> > Getting close here. Apparently gets to the linking phase. Please help
>> > with error below.
>> >
>> > [build$:618] (../src/configure --prefix=
Jacob Jacobson wrote:
>
> Getting close here. Apparently gets to the linking phase. Please help
> with error below.
>
>
> [build$:618] (../src/configure --prefix=/c/home/wrk/cygwin/install -v; make)
>>& make.out
> [build$:619] tail make.out
> /c/home/wrk/cygwin/build/i686-pc-cygwin/winsup/cygwin/..
--- Christopher Faylor wrote:
> Just remove the mingw directory.
--- I, Pedro, posted:
> $ tail make.out
> /opt/src/winsup/utils/mingw g++ -L/opt/build/i686-pc-cygwin/winsup
> -L/opt/build/
> i686-pc-cygwin/winsup/cygwin -L/opt/build/i686-pc-cygwin/winsup/w32api/lib
> -isys
> tem /opt/src/winsup
--- Christopher Faylor wrote:
> Just remove the mingw directory.
$ tail make.out
/opt/src/winsup/utils/mingw g++ -L/opt/build/i686-pc-cygwin/winsup -L/opt/build/
i686-pc-cygwin/winsup/cygwin -L/opt/build/i686-pc-cygwin/winsup/w32api/lib -isys
tem /opt/src/winsup/include -isystem /opt/src/winsup/cy
I'm, slowly, implementing it. I plan to post the papers tomorrow,
after my implementation work fine.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com
--- I asked:
>>> Will it be implemented in Cygwin someday?
--- Dave Korn replied:
>> Otherwise, http://cygwin.com/acronyms#SHTDI and
>> http://cygwin.com/acronyms#PTC apply here. I imagine it should be possible
>> to
>> use a windows job object to implement it.
--- Corinna Vinschen replied:
Will it be implemented in Cygwin someday?
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
--- I wrote:
>>> For me, using the unpatched version, (not the CVS version), the
>>> persistence works some times only. At other times the semaphore
>>> disappears with the Control c.
It is not reproducible.
I'm sorry from wasting your time.
--
Unsubscribe info: http://cygwin.com/ml/#
>> The persistence of the semaphore also works for you?
>>
>> For me, using the unpatched version, (not the CVS version), the
>> persistence works some times only. At other times the semaphore
>> disappears with the Control c.
>
> The semaphore is backed by a file on disk. If you don't call
>
Corinna Vinschen read my mind.
> What is semtool?
semtool - A utility for tinkering with semaphores
USAGE: semtool (c)reate
(l)ock
(u)nlock
(d)elete
(m)ode
It comes in some package available through the Cygwin's insta
Does the function sem_open work for anyone using Cygwin 1.7.0 ?
How to use semtool ?
I wrote an example that works on Jaunty on x86-64 but not on Cygwin:
http://www.izecksohn.com/pedro/c/semaphores/semaphores.tar.gz
Also: gcc4 does not understand the option "-lrt" so it must be removed.
> From: Christopher Faylor
>> I wrote:
>> Reference: http://sourceware.org/ml/cygwin/2008-02/msg00181.html
>> ...
>>
>> "SHELL The full pathname to the shell is kept in this environment variable."
>>
>> It may also be read from:
>>http://www.gnu.org/software/bash/manual/bashref.html
>
> Why are y
Reference: http://sourceware.org/ml/cygwin/2008-02/msg00181.html
"Are you sure SHELL was exported to the environment, and not just in the bash
shell variable namespace?"
It is a documentation problem, from man bash:
"SHELL The full pathname to the shell is kept in this environment variable."
I
I'm becoming an idiot. Every day I understand less:
bash-3.2$ file AWTPlayer.java
AWTPlayer.java: ASCII Java program text
bash-3.2$ unix2dos.exe AWTPlayer.java
AWTPlayer.java:
unix2dos processing AWTPlayer.java: Permission denied
bash-3.2$ unix2dos.exe < AWTPlayer.java > AWTPlayer2.java
bash-3.2
struct stat member st_mode is wrongly being set by the stat function to
regular file instead of to symlink.
I packed a test for download:
http://www.izecksohn.com/pedro/c/statbug/statbug.tar.gz
To use it:
tar -xzvf statbug.tar.gz
make
My configuration:
bash-3.2$ uname -a
CYGWIN_N
34 matches
Mail list logo
