ChangeLog entry:
2010-08-19 Pedro Izecksohn pedro.izecks...@...
* 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
--- 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 with
As this thread went nowhere, I searched for the BSD code:
http://svn.freebsd.org/viewvc/base/stable/8/sys/sys/endian.h?revision=199583view=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
--- 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.
--- Eric Blake ebl...@... 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
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 from a
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:
--- 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 default ed
--- 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
--- 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 /cygdrive/c
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
Robert Pendell shi...@... 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
I, Pedro Izecksohn pedro.izecks...@... wrote:
Robert Pendell shi...@... 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
r...@turion ~/programming/c/sigint
$ cat test.c
#include stdio.h
#include stdlib.h
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));
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.
Try Cygwin 1.7 http://cygwin.com/#beta-test.
$ cat /proc/version
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
Vinschencorinna-cyg...@cygwin.com wrote:
On Jul 27 22:56, Andy Koppe wrote:
To initialize wchar_t wc=(wchar_t)0; may also help.
On Tue, Jul 28, 2009 at 6:56 AM, Andy Koppeandy.ko...@gmail.com 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/mbrtowc.html
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
--- 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
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
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
--- 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
--- 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
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:
--- 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:
There
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
Corinna Vinschen read my mind.
What is semtool?
semtool - A utility for tinkering with semaphores
USAGE: semtool (c)reate semcount
(l)ock sem #
(u)nlock sem #
(d)elete
(m)ode mode
It comes in some package available
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
sem_unlink
--- 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:
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.
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.
It
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 you responding to
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
34 matches
Mail list logo
