On Wed, Aug 16, 2023 at 05:23:55PM -0400, Richard Kimberly Heck wrote:
>
> On 8/16/23 14:30, Scott Kostyshak wrote:
> > On Wed, Aug 16, 2023 at 05:48:57PM +0200, Pavel Sanda wrote:
> > > > ../../2.3.x/src/LyXRC.cpp:3077:42: warning: comparison between two
> > > > arrays
> > > > [-Warray-compare]
On 8/16/23 14:30, Scott Kostyshak wrote:
On Wed, Aug 16, 2023 at 05:48:57PM +0200, Pavel Sanda wrote:
../../2.3.x/src/LyXRC.cpp:3077:42: warning: comparison between two arrays
[-Warray-compare]
3077 | || lyxrc_orig.font_sizes != lyxrc_new.font_sizes
This one is a real bug thou
On Wed, Aug 16, 2023 at 05:48:57PM +0200, Pavel Sanda wrote:
>
> > ../../2.3.x/src/LyXRC.cpp:3077:42: warning: comparison between two arrays
> > [-Warray-compare]
> > 3077 | || lyxrc_orig.font_sizes != lyxrc_new.font_sizes
>
> This one is a real bug though, fixed at master by eae
On Wed, Aug 16, 2023 at 11:17:22AM +0200, Jean-Pierre Chrétien wrote:
> C++ Compiler:g++ (12.2.0)
...
> std::binary_function??? is deprecated [-Wdeprecated-declarations]
...
> _Result> struct std::unary_function??? is deprecated
...
> ???std::const_mem_fun_ref_t<_Ret, _Tp> std::mem_fu
Am Sonntag, dem 02.04.2023 um 13:21 +0200 schrieb Jürgen Spitzmüller:
> This needs some effort. For the time being, I think we will be better
> off with this rather harmless info message.
Possible approach attached.
--
Jürgen
diff --git a/src/Paragraph.cpp b/src/Paragraph.cpp
index c43421b376..4
Am Mittwoch, dem 22.03.2023 um 23:21 + schrieb Udicoudco:
> > > I attached a possible patch, it only fix the lstlisting case when
> > > polyglossia is used, since babel-hebrew does not have an
> > > equivalent
> > > to \begin{RTL}...\end{RTL} (or there is one?) and babel with
> > > luatex
> > >
On Wed, Mar 22, 2023 at 10:28 PM Udicoudco wrote:
>
> > I attached a possible patch, it only fix the lstlisting case when
> > polyglossia is used, since babel-hebrew does not have an equivalent
> > to \begin{RTL}...\end{RTL} (or there is one?) and babel with luatex
> > does not need this kind of w
> I attached a possible patch, it only fix the lstlisting case when
> polyglossia is used, since babel-hebrew does not have an equivalent
> to \begin{RTL}...\end{RTL} (or there is one?) and babel with luatex
> does not need this kind of wrappers.
I've added line breaks to the LaTeX code for
readabi
On Wed, Mar 22, 2023 at 2:22 PM Scott Kostyshak wrote:
>
> On Wed, Mar 22, 2023 at 01:13:27PM +0100, Jürgen Spitzmüller wrote:
> > Am Mittwoch, dem 22.03.2023 um 12:54 +0200 schrieb Udicoudco:
> > > I think in the case of where forceLTR insets will have multiple
> > > paragraphs, it is better to u
On Wed, Mar 22, 2023 at 01:13:27PM +0100, Jürgen Spitzmüller wrote:
> Am Mittwoch, dem 22.03.2023 um 12:54 +0200 schrieb Udicoudco:
> > I think in the case of where forceLTR insets will have multiple
> > paragraphs, it is better to use
> > \begin{RTL}...\end{RTL}, which basically only issues \par a
Am Mittwoch, dem 22.03.2023 um 12:54 +0200 schrieb Udicoudco:
> I think in the case of where forceLTR insets will have multiple
> paragraphs, it is better to use
> \begin{RTL}...\end{RTL}, which basically only issues \par and sets
> the
> RTL related conditionals
> to be false.
Thanks for the deta
Slight correction, the lines
>
> \@RTLfalse\beginL{
> \begin{lstlisting}
> Hello
> \end{lstlisting}
> }\endL
>
should be
{\@RTLfalse\beginL
\begin{lstlisting}
Hello
\end{lstlisting}
}\endL
and the lines
>
> \@RTLfalse\beginL{
> \par
> Hello
> \par
> }\endL
>
should be
{\@RTLfalse\beginL
On Tue, Mar 21, 2023 at 9:40 PM Scott Kostyshak wrote:
>
> On Tue, Mar 21, 2023 at 12:50:06PM +0100, Jürgen Spitzmüller wrote:
> > Am Dienstag, dem 21.03.2023 um 11:27 + schrieb Udicoudco:
> > > Hello all,
> > >
> > > Attached a LyX file and its export to LaTeX code.
> > > When compiling with
On Tue, Mar 21, 2023 at 12:50:06PM +0100, Jürgen Spitzmüller wrote:
> Am Dienstag, dem 21.03.2023 um 11:27 + schrieb Udicoudco:
> > Hello all,
> >
> > Attached a LyX file and its export to LaTeX code.
> > When compiling with XeLaTeX the exported code
> > I get the warning:
> >
> > \endL o
Am Dienstag, dem 21.03.2023 um 11:27 + schrieb Udicoudco:
> Hello all,
>
> Attached a LyX file and its export to LaTeX code.
> When compiling with XeLaTeX the exported code
> I get the warning:
>
> \endL or \endR problem (0 missing, 1 extra) in paragraph at lines
> 26--27
Interestingly,
Le 20/12/2020 à 11:37, Kornel Benko a écrit :
This works, but I just wondered why cmake did not need to compile any sources in
hunspell/1.7.0/src/parsers.
Do we need only the header files there?
Because we do not need this directory! I removed it.
Thanks,
JMarc
--
lyx-devel mailing list
lyx-d
Am Sat, 19 Dec 2020 20:57:24 +0100
schrieb Jean-Marc Lasgouttes :
> Le 17/12/2020 à 11:46, Kornel Benko a écrit :
> > Am Thu, 17 Dec 2020 11:40:36 +0100
> > schrieb Jean-Marc Lasgouttes :
> I guess it can wait for 2.3.7. Looking at "git log" for
> 3rdparty/hunspell, there is one main c
Le 17/12/2020 à 11:46, Kornel Benko a écrit :
Am Thu, 17 Dec 2020 11:40:36 +0100
schrieb Jean-Marc Lasgouttes :
I guess it can wait for 2.3.7. Looking at "git log" for
3rdparty/hunspell, there is one main commit (c3484fa6c), 2 fixups
(91c58d9a68ca2 and cf980435b), plus a fistful of commits by Ko
Am Thu, 17 Dec 2020 11:40:36 +0100
schrieb Jean-Marc Lasgouttes :
> Le 02/11/2020 à 19:44, Richard Kimberly Heck a écrit :
> > On 11/2/20 12:16 PM, Jean-Marc Lasgouttes wrote:
> >> Le 02/11/2020 à 16:59, Richard Kimberly Heck a écrit :
> Yes, hunspell has been updated in master to 1.7.0,
Le 02/11/2020 à 19:44, Richard Kimberly Heck a écrit :
On 11/2/20 12:16 PM, Jean-Marc Lasgouttes wrote:
Le 02/11/2020 à 16:59, Richard Kimberly Heck a écrit :
Yes, hunspell has been updated in master to 1.7.0, but not in
branch. Riki, would it make sense to do that, given that we want to
leave
Le 02/11/2020 à 15:39, Jean-Pierre Chrétien a écrit :
Dear developers
While compiling the latest branch with this config
I see this :
../../../2.3.x/3rdparty/hunspell/1.6.2/src/hunspell/hunspell.cxx: In
member function ‘bool HunspellImpl::spell(const string&, int*,
std::__cxx11::string*)’:
On 12/16/2017 09:59 AM, Kornel Benko wrote:
> Open with lyx-master src/tex2lyx/test/test-insets.lyx.lyx:
> => many lines like this:
> + sys.argv[4])) != 0:
> IndexError: list index out of range
> Traceback (most recent call last):
> File "/usr/local/share/lyx2.4/scripts/co
On Thu, Feb 18, 2016 at 10:26:54AM +0100, Buenas Noticias wrote:
> Hi all:
>
> When I want to see the article I'm writing in PS, do not open and I get the
> following warnings:
>
> - Missing glyphs!
>
> - Missing character: There is no in font LinBiolinumT-tlf-ts1!
>
> Can you help me?
Hi Mig
Jean-Marc Lasgouttes wrote:
> Le 09/06/2015 15:00, Richard Heck a écrit :
>>
>> Using automake 1.15 (though I think I also saw this earlier), I get a
>> ton of warnings like:
>>
>> src/tex2lyx/Makefile.am:71: warning: source file '../version.cpp' is in
>> a subdirectory,
>> src/tex2lyx/Makefile.am
On 06/10/2015 04:42 AM, Jean-Marc Lasgouttes wrote:
Le 09/06/2015 15:00, Richard Heck a écrit :
Using automake 1.15 (though I think I also saw this earlier), I get a
ton of warnings like:
src/tex2lyx/Makefile.am:71: warning: source file '../version.cpp' is in
a subdirectory,
src/tex2lyx/Makefi
Le 09/06/2015 15:00, Richard Heck a écrit :
Using automake 1.15 (though I think I also saw this earlier), I get a
ton of warnings like:
src/tex2lyx/Makefile.am:71: warning: source file '../version.cpp' is in
a subdirectory,
src/tex2lyx/Makefile.am:71: but option 'subdir-objects' is disabled
I'
Le 04/05/2015 17:39, Jürgen Spitzmüller a écrit :
Should be solved.
It is. Thanks.
JMarc
2015-05-04 14:49 GMT+02:00 Jean-Marc Lasgouttes:
> Hello,
>
> With today's build, I get the following warning. Juergen, is this related
> to your recent changes?
>
For sure.
> GENui_TabularCreateUi.h
> ../../../../master/src/frontends/qt4/ui/TabularCreateUi.ui: Warning:
> Z-order assignme
2013/1/29 Richard Heck:
> Having just upgraded to Fedora 17, I am now seeing this kind of thing:
>
> CXXlstrings.o
> In file included from ../../boost/boost/config.hpp:44:0,
> from ../../boost/boost/static_assert.hpp:17,
> from ../../boost/boost/iterator/iter
Am 07.10.2011 um 09:43 schrieb Tommaso Cucinotta:
> Current trunk gives these warnings, which seem related to me.
>
> Buffer.cpp:4197:42: warning: suggest parentheses around ‘&&’ within ‘||’
>
> int Buffer::spellCheck(DocIterator & from, DocIterator & to,
> [...]
> // If from is at the end of th
On 02/02/2011 12:38 PM, Richard Heck wrote:
On 02/02/2011 12:32 PM, rgh...@lyx.org wrote:
Author: rgheck
Date: Wed Feb 2 18:32:59 2011
New Revision: 37427
URL: http://www.lyx.org/trac/changeset/37427
Log:
More related to #7224: It's OK for layouts not to provide a ListCommand
if a float writes
On 10/12/2010 08:15 PM, Pavel Sanda wrote:
Pavel Sanda wrote:
when opening or creating new files in trunk is see on the console messages like:
Warning: 83
Warning: 34
i guess this has something to do with last changes in lyx2lyx. try to open eg
additional manual.
newly saved files d
> i guess this has something to do with last changes in lyx2lyx.
Yes, it was a debug warning I forgot to delete before committing. I removed it
now.
regards Uwe
Pavel Sanda wrote:
> when opening or creating new files in trunk is see on the console messages
> like:
>
> Warning: 83
> Warning: 34
i guess this has something to do with last changes in lyx2lyx. try to open eg
additional manual.
newly saved files do not have it.
>
> pavel
Dov Feldstern wrote:
So now the question is: do we need this function at all at this point?
Since it seems to have been doing nothing for the past three years, can
we just get rid of it? Does anyone know if what the code that's in there
*should* have been doing is still needed?
You should nev
Angus Leeming wrote:
Pavel Sanda wrote:
Pavel Sanda wrote:
I purposely left RC_VISUAL_CURSOR out of this function, because
something is fishy about it. AFAICT, this function doesn't do
anything... JMarc took a look and I think he also wasn't sure about
it... So before just fixing the warnings
Pavel Sanda wrote:
Pavel Sanda wrote:
I purposely left RC_VISUAL_CURSOR out of this function, because something
is fishy about it. AFAICT, this function doesn't do anything... JMarc
took a look and I think he also wasn't sure about it... So before just
fixing the warnings, we ought to try and
> Pavel Sanda wrote:
>>> I purposely left RC_VISUAL_CURSOR out of this function, because something
>>> is fishy about it. AFAICT, this function doesn't do anything... JMarc
>>> took a look and I think he also wasn't sure about it... So before just
>>> fixing the warnings, we ought to try and fig
Pavel Sanda wrote:
I purposely left RC_VISUAL_CURSOR out of this function, because something
is fishy about it. AFAICT, this function doesn't do anything... JMarc took
a look and I think he also wasn't sure about it... So before just fixing
the warnings, we ought to try and figure out what this
> I purposely left RC_VISUAL_CURSOR out of this function, because something
> is fishy about it. AFAICT, this function doesn't do anything... JMarc took
> a look and I think he also wasn't sure about it... So before just fixing
> the warnings, we ought to try and figure out what this function *s
Richard Heck wrote:
LyXFunc.cpp: In function 'void lyxactOnUpdatedPrefs(const
lyx::LyXRC&, const lyx::LyXRC&)':
LyXFunc.cpp:1885: warning: enumeration value 'RC_FULL_SCREEN_LIMIT' not
handled in switch
LyXFunc.cpp:1885: warning: enumeration value 'RC_FULL_SCREEN_SCROLLBAR'
not handled in sw
> LyXFunc.cpp: In function 'void lyxactOnUpdatedPrefs(const
> lyx::LyXRC&, const lyx::LyXRC&)':
> LyXFunc.cpp:1885: warning: enumeration value 'RC_FULL_SCREEN_LIMIT' not
> handled in switch
> LyXFunc.cpp:1885: warning: enumeration value 'RC_FULL_SCREEN_SCROLLBAR' not
> handled in switch
> Ly
Andre Poenitz wrote:
> ../../trunk/src/LyXFunc.cpp:2477: warning: enumeration value
> 'RC_DEFFILE' not handled in switch
> ../../trunk/src/LyXFunc.cpp:2477: warning: enumeration value
> 'RC_USE_PIXMAP_CACHE' not handled in switch
The latter is fixed. This is commented-out code btw.
Jürgen
Dov Feldstern wrote:
Hi!
There are a few warnings in Paragraph.cpp, if anyone cares to take a look:
Paragraph.cpp: In member function 'void
lyx::Paragraph::Private::insertChar(lyx::pos_type, lyx::char_type, const
lyx::Change&)':
Paragraph.cpp:415: warning: comparison between signed and unsign
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
This should be fixed:
Interesting (I don't have the warning with MSVC). I'll see what I can do.
The declaration order is different to the order of the initialization.
MSVC did not warn about this. To fix it we must only change t
Abdelrazak Younes wrote:
> Georg Baum wrote:
>> This should be fixed:
>
> Interesting (I don't have the warning with MSVC). I'll see what I can do.
>
The declaration order is different to the order of the initialization.
MSVC did not warn about this. To fix it we must only change the order
of th
Georg Baum wrote:
This should be fixed:
Interesting (I don't have the warning with MSVC). I'll see what I can do.
Thanks,
Abdel.
Georg Baum <[EMAIL PROTECTED]> writes:
| > Hmm... but you don't play with CPPFLAGS... should possibly be an
| > additional check for CPPFLAGS then.
|
| Exactly. The attached patch does exactly that. I am going to commit this
| soon.
I am not super sure that we should do this, but we might just
Am Sonntag, 30. Juli 2006 15:56 schrieb Lars Gullik Bjønnes:
> Georg Baum <[EMAIL PROTECTED]> writes:
>
> | Why? CPPFLAGS should always be set IMO if the user did not set them.
>
> No. If _you_ play with CXXFLAGS, then _you_ are in charge and we bow
> to your decisions.
Of course.
> Hmm... but
Georg Baum <[EMAIL PROTECTED]> writes:
| Am Sonntag, 30. Juli 2006 12:43 schrieb Lars Gullik Bjønnes:
|
| > From lyxinclude.m4:
| >
| > 3.4*|4.0*)
| > AM_CXXFLAGS=""
| > test $enable_pch = yes && lyx_pch_comp=yes
| > ;;
| >
| >
| > 3.4*|4.0*)
| > lyx
Am Sonntag, 30. Juli 2006 12:43 schrieb Lars Gullik Bjønnes:
> From lyxinclude.m4:
>
> 3.4*|4.0*)
> AM_CXXFLAGS=""
> test $enable_pch = yes && lyx_pch_comp=yes
> ;;
>
>
> 3.4*|4.0*)
> lyx_flags="stdlib-debug $lyx_flags"
> AC_DEFINE(_GLIBCXX_DE
Georg Baum <[EMAIL PROTECTED]> writes:
| Am Sonntag, 30. Juli 2006 12:24 schrieb Lars Gullik Bjønnes:
| > Georg Baum <[EMAIL PROTECTED]> writes:
| >
| > | I just noticed that I do not get compiler warnings anymore with current
| > | svn. --enable-warnings does not help. The 1.4 branch works fine
Am Sonntag, 30. Juli 2006 12:24 schrieb Lars Gullik Bjønnes:
> Georg Baum <[EMAIL PROTECTED]> writes:
>
> | I just noticed that I do not get compiler warnings anymore with current
> | svn. --enable-warnings does not help. The 1.4 branch works fine.
> | Does anybody else see this?
>
> Compiler ve
Georg Baum <[EMAIL PROTECTED]> writes:
| I just noticed that I do not get compiler warnings anymore with current
| svn. --enable-warnings does not help. The 1.4 branch works fine.
| Does anybody else see this?
Compiler version?
--
Lgb
Lars Gullik Bjønnes wrote:
| /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/helper_funcs.C,v
> | retrieving revision 1.41 diff -u -p -r1.41 helper_funcs.C
> | --- src/frontends/controllers/helper_funcs.C16 May 2005 09:14:16
> | - 1.41
> | +++ src/frontends/controllers/
Angus Leeming <[EMAIL PROTECTED]> writes:
| Angus Leeming wrote:
|
| > Not too many of them...
| > Angus
| >
| The attached patch squashes these three:
|
| > graphicscacheitem.c(387):
| > warning C4706: assignment within conditional expression
|
| > helper_funcs.c(149):
| > warning C4706: ass
Angus Leeming wrote:
> Not too many of them...
> Angus
>
The attached patch squashes these three:
> graphicscacheitem.c(387):
> warning C4706: assignment within conditional expression
> helper_funcs.c(149):
> warning C4706: assignment within conditional expression
> lyxtextclass.c(287): warni
On Sun, Oct 30, 2005 at 09:44:21AM +, Angus Leeming wrote:
> On Sunday 30 October 2005 08:55, Martin Vermeer wrote:
> > On Sat, Oct 29, 2005 at 09:20:43PM +0100, Angus Leeming wrote:
> > > Not too many of them...
> > > Angus
> > >
> > >
> > > j:\MSYS\home\Angus\LyX\devel\src\text2.C(996): warni
On Sat, Oct 29, 2005 at 09:20:43PM +0100, Angus Leeming wrote:
> Not too many of them...
> Angus
> j:\MSYS\home\Angus\LyX\devel\src\text2.C(996): warning C4189: 'boundary' :
> local variable is initialized but not referenced
Good Dog!
- Martin
pgpvkdkneKBG7.pgp
Description: PGP signature
On Sunday 30 October 2005 08:55, Martin Vermeer wrote:
> On Sat, Oct 29, 2005 at 09:20:43PM +0100, Angus Leeming wrote:
> > Not too many of them...
> > Angus
> >
> >
> > j:\MSYS\home\Angus\LyX\devel\src\text2.C(996): warning C4189: 'boundary'
> > : local variable is initialized but not referenced
>
Michael Schmitt wrote:
> Angus,
>
> using MinGW, I get tons of warnings like this one:
>
> C:/msys/home/Brother/qt-3/include/private/qucom_p.h:393: warning: inline
> function 'virtual void QUType_int::clear(QUObject*)' is declared as
> dllimport: attribute ignored.
Me too. They're a PITA.
> I
Thanks, I've applied the attached patch to fix these.
John
On Mon, 2004-11-29 at 20:45 +0100, Georg Baum wrote:
> I get the following warnings:
>
> ../../../../src/frontends/gtk/FileDialogPrivate.h: In constructor `
>FileDialog::Private::Private(const std::string&, kb_action,
>std::pair,
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> A fresh build (new build-dir) results in the user being
Angus> confronted with this (below). Seems a bit of a shame to give
Angus> 'em food for thought in such a visble spot.
Angus> The culprit is lib/reLyX/configure, but I cannot
Jean-Marc Lasgouttes wrote:
>
> > "R" == R Lahaye <[EMAIL PROTECTED]> writes:
>
> R> Jean-Marc Lasgouttes wrote:
> >> > "R" == R Lahaye <[EMAIL PROTECTED]> writes:
> >>
> R> Hi,
> >>
> R> Below is a list of warnings I get during my compile. Is that
> R> useful?
> >> Probably. What vers
> "R" == R Lahaye <[EMAIL PROTECTED]> writes:
R> Jean-Marc Lasgouttes wrote:
>> > "R" == R Lahaye <[EMAIL PROTECTED]> writes:
>>
R> Hi,
>>
R> Below is a list of warnings I get during my compile. Is that
R> useful?
>> Probably. What version of g++ is that? Are you sure you updated to
>>
Jean-Marc Lasgouttes wrote:
>
> > "R" == R Lahaye <[EMAIL PROTECTED]> writes:
>
> R> Hi,
>
> R> Below is a list of warnings I get during my compile. Is that
> R> useful?
>
> Probably. What version of g++ is that? Are you sure you updated to
> latest cvs?
Yes, it's the latest CVS.
I'm usin
> "R" == R Lahaye <[EMAIL PROTECTED]> writes:
R> Hi,
R> Below is a list of warnings I get during my compile. Is that
R> useful?
Probably. What version of g++ is that? Are you sure you updated to
latest cvs?
JMarc
On Tue, Apr 16, 2002 at 11:43:45PM +0200, Lars Gullik Bjønnes wrote:
> ../../../src/mathed/formulamacro.C:192: warning: passing `float' for argument 2
>of `virtual void MathInset::draw(Painter&, int, int) const'
Fixed.
Andre'
--
Those who desire to give up Freedom in order to gain Security
On 03-Apr-2001 R. Lahaye wrote:
> CutAndPaste.C: In function `static bool CutAndPaste::checkPastePossible(LyXParagraph
> *)':
> CutAndPaste.C:543: warning: unused parameter `class LyXParagraph * par'
Fixed!
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
I think this has been fixed; keep the errors (and warnings) coming...
A
On Tuesday 20 March 2001 00:43, R. Lahaye wrote:
> math_macro.C: In method `void MathMacro::Metrics()':
> math_macro.C:77: warning: comparison between signed and unsigned
> math_macro.C: In method `bool MathMacro::setArgume
On 25-Feb-2000 Jean-Marc Lasgouttes wrote:
>
> I get the following warnings when compiling with cxx (I get others
> too, but I have corrected them in my tree). Is there a reason why
> UpdatableInset::InsertInset() and UpdatableInset::SetFont() do not have
> the BufferView* parameter?
>
> cxx: W
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Or we could somehow discover that it is compiled built in a CVS
Lars> checkedout dir? (vpath builds?) I am not sure how this could be
Lars> done...do we have some files that are only present in in CVS
Lars> checked out dirs? Hm
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> I am a bit reluctant to remove the -pedantic especially since it
| Lars> is only used for devel versions. (we should probably change the
| Lars> criteria for devel version
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> I am a bit reluctant to remove the -pedantic especially since it
Lars> is only used for devel versions. (we should probably change the
Lars> criteria for devel version a bit...)
OK, what should we use? Search for pre in the na
Juergen Vigna <[EMAIL PROTECTED]> writes:
| support/lstrings.h:68: warning: ANSI C++ forbids braced-groups within expressions
|
| And in some other functions too. Should this be fixed?
Actually all of these are the same error... tolower is implemented as
a macro that calls __tobody which is als
75 matches
Mail list logo
